BrandonFors/pandas-github-issues huggingface dataset:
STYLE use force-grid-wrap in isort
State: closed

- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them

As discussed in the monthly dev meeting - motivation here is to reduce the number of merge conflicts, which single-line imports seem to be a major source of.

some examples of such conflicts (which `force_grid_wrap` would avoid):

#37467 : 
```python
<<<<<<< GH37278
from typing import TYPE_CHECKING, Optional
=======
from __future__ import annotations

from typing import TYPE_CHECKING
>>>>>>> master
```

#34426 : 
```python
<<<<<<< 8745-from_dummies
from typing import TYPE_CHECKING, Any, Dict, Hashable, List, Optional, Type, Union, cast
=======
from typing import (
    TYPE_CHECKING,
    Dict,
    Hashable,
    List,
    Optional,
    Sequence,
    Type,
    TypeVar,
    Union,
    cast,
)
>>>>>>> master
```

#29944 :
```python
<<<<<<< subplot_groups
from collections import Counter, Iterable
from typing import TYPE_CHECKING, Hashable, List, Optional, Sequence, Tuple, Union
=======
from __future__ import annotations

from typing import TYPE_CHECKING, Hashable, List, Optional, Tuple
>>>>>>> master
```

----

This changes a huge number of files in one go, but all I've done is
```
git reset --hard upstream/master
# add `force_grid_wrap` option to setup.cfg
pre-commit run isort -a
git commit -m 'force grid-wrap' -a
```

Labels:
name: Code Style
description: Code style, linting, code_checks

Comments:
i think this is fine. please merge master and ping when green so can merge.
thanks @MarcoGorelli
STYLE, CI move validate_rst_title_capitalization check to pre-commit
State: closed

- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them

xref #39624 in which it took ~15 minutes for @rhshadrach to be told

```
Heading capitalization formatted incorrectly. Please correctly capitalize "pytest.xfail" to "Pytest.xfail" 
```

, like this such feedback will be provided much faster

Labels:
name: CI
description: Continuous Integration
name: Code Style
description: Code style, linting, code_checks

Comments:
thanks @MarcoGorelli
STYLE use absolute imports in asv_bench
State: closed

- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them

No longer limiting `abs-imports` to just pandas. This requires telling `isort` that `benchmarks` is a local folder, else it groups it with third-party imports

Labels:
name: Code Style
description: Code style, linting, code_checks

Comments:
IMO this is not an improvement in code clarity. The current `from .pandas_vb_common import` makes it very explicit that it is from a local file. When changing this to `from benchmarks...`, it might seem that this is some existing `benchmarks` package that is being imported.
> IMO this is not an improvement in code clarity. The current `from .pandas_vb_common import` makes it very explicit that it is from a local file. When changing this to `from benchmarks...`, it might seem that this is some existing `benchmarks` package that is being imported.

that's a good point - Isn't it clear from the sections though? As in, if there is

```python
import numpy as np

import pandas as pd

from benchmarks.pandas_vb_common import tm
```
then it's clear that `benchmarks` is a local folder, because it appears after `pandas` and wasn't grouped with the `numpy` import. If it was a third-party package, it would appear as

```python
from benchmarks.pandas_vb_common import tm
import numpy as np

import pandas as pd
```

No objection to closing though if you prefer these to be relative imports
> Isn't it clear from the sections though?

But then you need to know our ordering rules by heart to infer it from that (personally I never care about ordering and just let isort fix it). I know that for code within the pandas package the pandas imports always come last (so that's an easy rule to remember), but in this case 1) it are not imports from pandas, but from some `benchmarks` package and 2) personally for other code I almost always import more specialized packages after numpy and pandas, so this is a rather general pattern I think contributors might be used to (at least I am). 

For me the main question is: what's the benefit? Does it make code more readable, or does it help automating style issues? (But did we ever have a problem with a person doing relative imports in the benchmarls that we didn't want and thus an automatic style check would be hepful?)

(and to be clear, I am very much in favor *generally* of automatic checks for certain things (and thanks a lot for your work on that), but we should still always question the reason for adding one)
Thanks @jorisvandenbossche , that's a good point

> what's the benefit? 

I was just thinking that it would be clearer to have a rule applied everywhere rather than having `files: ^pandas/` - closing then, as I now think it's probably not worth it
BUG: incorrectly accepting datetime64(nat) for dt64tz
State: closed

- [ ] closes #xxxx
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry


Labels:
name: Missing-data
description: np.nan, pd.NaT, pd.NA, dropna, isnull, interpolate

Comments:
is this user facing at all?
> is this user facing at all?

yes.  `DatetimeIndex[tz].insert(np.datetime64("NaT"))` now casts to object, and a bunch of the TestSetitemNADatetime64Dtype tests fail in master
> > is this user facing at all?
> 
> yes. `DatetimeIndex[tz].insert(np.datetime64("NaT"))` now casts to object, and a bunch of the TestSetitemNADatetime64Dtype tests fail in master

kk can you add a whatsnew :->
whatsnew added + green

looking forward to the follow-up that de-duplicates a bunch of tests
DEPR: casting date to dt64 in maybe_promote
State: closed

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry

Once enforced, maybe_promote behavior will match DatetimeArray._validate_setitem_value and infer_dtype_from_scalar

sits on top of #39743

Labels:
name: Missing-data
description: np.nan, pd.NaT, pd.NA, dropna, isnull, interpolate
name: Deprecate
description: Functionality to remove in pandas

Comments:
> great can you add a whatsnew :>

whatsnew added + green
thanks!
nice.  getting close to done with the maybe_promote stuff.  big outstanding one is #39769, then just numeric dtypes left
> nice. getting close to done with the maybe_promote stuff. big outstanding one is #39769, then just numeric dtypes left

done too!
BUG: pd.show_versions: json.decoder.JSONDecodeError
State: closed

- [ x] closes #39701
- [ x] tests added / passed
- [ x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry


Labels:
name: Bug
name: Dependencies
description: Required and optional dependencies

Comments:
Hello @alexprincel! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2021-02-22 18:00:28 UTC
Not sure if this needs commenting (again, first-timer), but I believe I have implemented all requested changes and made testing more robust.
@alexprincel Looking at the diff, it looks like a merge went wrong somewhere. Can you fix this up?
> @alexprincel Looking at the diff, it looks like a merge went wrong somewhere. Can you fix this up?

Sorry about that. What seems to be the problem? I will do my best to resolve it. My git skills are not yet up to par.
@alexprincel If you click on ```Files changed```, you can see that there are unrelated changes in the ```pandas/tests/io``` directory. (Which I suspect is the result of a bad merge) I'm not really an expert on git either, so maybe you can ask one of the other maintainers for help.(If necessary you can revert the changes manually). Apart from the unrelated changes, LGTM. 
> @alexprincel If you click on `Files changed`, you can see that there are unrelated changes in the `pandas/tests/io` directory. (Which I suspect is the result of a bad merge) I'm not really an expert on git either, so maybe you can ask one of the other maintainers for help.(If necessary you can revert the changes manually). Apart from the unrelated changes, LGTM.

I saw this as well after. I have been reading on git this week and trying some things on test repos just to understand exactly what I need to do to correct this. If I can't figure it out I'll just start a new branch, put the modified files in that branch's working directory and commit that.
If you only need to revert a handful of files, I'd suggest
```bash
git remote -v  # check that `upstream` is pandas-dev/pandas and `origin` is alexprincel/pandas
git fetch upstream master
git checkout upstream/master -- pandas/tests/io
git commit -m 'revert unrelated changes'
git push origin alexdev
```
> Thanks @alexprincel for updating - I think this almost ready, just a couple of minor comments

Will make them later today. Thanks for your comments, helps me improve.
I have addressed all comments. Thanks !
LGTM
cool - merging then, as commit `02e6bc7` was green and the commit following that just changed a comment

Thank you @alexprincel !
> cool - merging then, as commit `02e6bc7` was green and the commit following that just changed a comment
> 
> Thank you @alexprincel !

Thank you for your patience on this! Hopefully I will be more efficient on my next PR.
BUG/REF: Refactor BaseWindowIndex so groupby.apply has a consistent index output
State: closed

- [x] closes #39732
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry


Labels:
name: Bug
name: Refactor
description: Internal refactoring of code
name: Window
description: rolling, ewma, expanding

Comments:
lgtm. can merge on green.
CI failures were related to the timedelta issue that has already been fixed
DOC: Ban mutation in UDF methods
State: closed

- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry

Ref: #12653. I added the message to apply, aggregate, transform, and groupby's filter. Not sure if this needs a whatsnew.

cc @jbrockmendel

Labels:
name: Docs
name: Apply
description: Apply, Aggregate, Transform, Map

Comments:
thanks @rhshadrach
CLN: maybe_promote doesnt need to support EA dtypes
State: closed

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry


Labels:
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
nice
[ArrayManager] TST: arithmetic test
State: closed

xref https://github.com/pandas-dev/pandas/issues/39146/

Labels:
name: Testing
description: pandas testing functions or related to the test suite
name: Numeric Operations
description: Arithmetic, Comparison, and Logical operations
name: Internals
description: Related to non-user accessible pandas implementation

Comments:
one request https://github.com/pandas-dev/pandas/pull/39753#discussion_r575583968, otherwise LGTM
ENH: Implement rounding for floating dtype array #38844
State: closed

Code proposed in the staled PR #38866

- [x] closes #38844
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry


Labels:
name: Enhancement
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
can you merge master
Thanks for all your reviews! I will take time to implement them, but I can't before Saturday.
I pushed some modifications:
- I added a small `test_function.py` in `tests/arrays/masked/`
- I merged the `_apply` and the `round` methods to have only the `round` method
- I merged master
some precommit issues

```
Performing static analysis using mypy
pandas/core/arrays/numeric.py:241: error: "T" has no attribute "_data"  [attr-defined]
pandas/core/arrays/numeric.py:242: error: Too many arguments for "object"  [call-arg]
pandas/core/arrays/numeric.py:242: error: "T" has no attribute "_mask"  [attr-defined]
Found 3 errors in 1 file (checked 1242 source files)
```
@jreback two tests failed in code that I did not write/modify? Is this normal?
thanks for merging master @benoit9126 this lgtm.
thanks @benoit9126 
Thanks a lot @benoit9126 !
DOC: added more and updated links in cheat sheet
State: closed

- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry


Labels:
name: Docs

Comments:
can you say what you changed here.

cc @Dr-Irv 
I created this PR #39707 (which was essentially the same) and it was merged yesterday with master. However, I checked in [pandas-dev:master](https://github.com/pandas-dev/pandas/tree/master/doc/cheatsheet) and my changes don't appear there. The changes in the cheat sheet should look like [this](https://github.com/OliEfr/pandas/blob/master/doc/cheatsheet/Pandas_Cheat_Sheet.pdf).

That is why I created another this PR which is essentially the same.

(I used to use a [pullBot](https://wei.github.io/pull/) to stay up to date with master. I figured, that my changes might have been reversed by the pullbot?! Now I am not using a pullbot anymore.)

This is my first contribution to a larger OSS-Project and I am kind of confused by the automated tests. I am not sure how to fix the failing tests. Merging with master didn't help.

Sorry for confusion.


@jreback He added hyperlinks to the documentation from the cheat sheet.  I compared the current and his changes, and it looks fine to me.  Nice idea.   I merged it in.

Thanks @OliEfr 
Oh, thanks very much :) Happy to contribute!
CI: share pandas setup steps
State: closed

Split out from https://github.com/pandas-dev/pandas/pull/39392. Just a refactor; puts redundant setup steps in a shared place.

To be honest, I don't actually understand why different GitHub Actions set up pandas in different ways, so didn't change that here.

The `uses` calls can be moved into the composite actions once https://github.com/actions/runner/issues/862 is complete, DRYing it up even more.

- [ ] ~~closes #xxxx~~
- [ ] tests ~~added /~~ passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] ~~whatsnew entry~~


Labels:
name: Refactor
description: Internal refactoring of code
name: CI
description: Continuous Integration

Comments:
thanks @afeld
CI: fix reference to take_1d()
State: closed

Fix for issue noted by @lithomas1 in https://github.com/pandas-dev/pandas/pull/39731#issuecomment-777179836, which is causing the Benchmarks to fail.

- [ ] ~~closes #xxxx~~
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] ~~whatsnew entry~~


Labels:
name: Bug
name: CI
description: Continuous Integration

Comments:
`CI / Checks` passed, which is what was failing [before this pull request](https://github.com/pandas-dev/pandas/runs/1875678358?check_suite_focus=true#step:14:46). I believe the other failures are flaky tests.
BUG: maybe_promote with dt64tz and mismatched NA
State: closed

- [ ] closes #xxxx
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry


Labels:
name: Bug
name: Dtype Conversions
description: Unexpected or buggy dtype conversions

Comments:
user facing?
> user facing?

trying to track this down; many of the cases that _would_ be affected go through DTA/TDA/PA methods instead of maybe_promote
> user facing?

so far it looks like the answer is "no", but that the reason involves incorrect NAs being ignored somewhere else that i need to track down separately
> user facing?

increasingly looking like "no"
OK im now almost positive there is nothing user-facing bc 1) the only currently-incorrect case is in the dt64tz path and 2) that path is AFAICT not reachable by any of the non-test uses of maybe_promote
ok can you rebase
rebased + green (no longer a bugfix, just a refactor)
CI: enable arm64 build on drone.io #39730
State: closed

- [x] closes #39730
xref #36719



Labels:
name: CI
description: Continuous Integration
name: ARM
description: aarch64 architecture

Comments:
a couple of thoughts here.

- can you make multiple sections on drone, e.g. setup / build / test (mainly to separate out the building from the testing).
- you can just start with very minimal deps, e.g. numpy & dateutil  to make this faster.
great this looks like its running now; i would xfail the tests that are failing and open an issue for them.
xref #38921 #38923

xpass #38798
hmm looks like it is timing out, for sure skip the slow tests. maybe have to see what is slow on arm and re-add back the arm_slow (or similar) to skip more.
The building phase took either 4 min or 14 min. Not sure why.
![drone_build_23](https://user-images.githubusercontent.com/7614606/110981605-fb215f00-832c-11eb-9ccc-8d86d03f5c4e.PNG)
![drone_build_24](https://user-images.githubusercontent.com/7614606/110981620-feb4e600-832c-11eb-97e6-69ecdc552e77.PNG)

@jreback I asked Drone about the performance issue https://discourse.drone.io/t/unstable-performance-on-arm64/8833. This is the response: 

> Drone Cloud (cloud.drone.io) is our personal Drone instance that we make available to the public for testing and evaluation purposes; it has limited capacity. Once you evaluate the product, you should decide whether or not you want to install Drone on your own infrastructure (the same way you would install Jenkins). Drone is meant to be a Jenkins alternative (self-hosted) as opposed to a Travis alternative (saas).



so basically this is unusable :(

iirc numpy does build arm for CI but i don't recall exactly where

cc @seberg 
We did not move away from TravisCI, instead apparently the right tree got shaken and (apparently enough) credits fell out: https://github.com/numpy/numpy/issues/17824#issuecomment-733878761

Is that is what you were asking?  I suppose that should also work for pandas, but I am not sure about the correct "process" for it. Maybe pinging those involved directly, although it would be nice if there was a better solution after the initial quick policy-change...
Let's find the right tree :)
i am going to hook us up with circleci which i think supports arm (or does so via a docker image)
Changed pct_change parameters to calculate pct_change right-to-left f…
State: closed

…or axis=1.

- [ ] closes #39672
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- For axis = 1, periods = -periods.


Labels:

Comments:
Hello @andrei-assa! Thanks for opening this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:

* In the file [`pandas/core/generic.py`](https://github.com/pandas-dev/pandas/blob/4f1724810740210e39fea36473ad5acdd0687dae/pandas/core/generic.py):

> [Line 10209:89](https://github.com/pandas-dev/pandas/blob/4f1724810740210e39fea36473ad5acdd0687dae/pandas/core/generic.py#L10209): [E501](https://duckduckgo.com/?q=pep8%20E501) line too long (91 > 88 characters)
> [Line 10211:89](https://github.com/pandas-dev/pandas/blob/4f1724810740210e39fea36473ad5acdd0687dae/pandas/core/generic.py#L10211): [E501](https://duckduckgo.com/?q=pep8%20E501) line too long (90 > 88 characters)


> closes #39672

The issue just involves slightly changing the example in the docs, the source code shouldn't need changing
> The issue just involves slightly changing the example in the docs, the source code shouldn't need changing

Fully agree.  It is not reasonable to change the behavior of `pct_change` when applied across columns. It should be the case that `pct_change(periods=n)` should be the change from `df.iloc[:-n]` to `df.iloc[n:]` for positive `n` and `df.iloc[n:]` to `df.iloc[:-n]` for negative `n`. Adding an axis shouldn't change this behavior, and when computed across columns `pct_change(periods=n)` should be the change from `df.iloc[:,:-n]` to `df.iloc[:,n:]` for positive `n` and `df.iloc[:,n:]` to `df.iloc[:,:-n]` for negative `n`
closed in #40266 , thanks anyway @andrei-assa for your PR
BUG: Timedelta input string with only symbols and no digits raises an error (GH39710)
State: closed

- [x] closes #39710
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry


Labels:
name: Error Reporting
description: Incorrect or improved errors from pandas
name: Timedelta
description: Timedelta data type

Comments:
thanks @avinashpancham
[ArrayManager] Indexing - implement iset
State: closed

xref https://github.com/pandas-dev/pandas/issues/39146/, follow-up on https://github.com/pandas-dev/pandas/pull/39722

Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Internals
description: Related to non-user accessible pandas implementation

Comments:
lgtm. @jbrockmendel 
LGTM
REF: remove take_1d alias of take_nd
State: closed

@jreback as discussed in https://github.com/pandas-dev/pandas/pull/39692

Since this is just an alias, this is certainly fine in theory. Although now doing it, I think there is still *some* value of the alias to signal that it is taking a 1D array which can provide useful context when *reading* code that uses this.

Labels:
name: Clean

Comments:
> @jreback as discussed in #39692
> 
> Since this is just an alias, this is certainly fine in theory. Although now doing it, I think there is still _some_ value of the alias to signal that it is taking a 1D array which can provide useful context when _reading_ code that uses this.

right . i think your next take_1d_array will make more sense (and consider actually naming IT take_1d)
Yes, but I am not directly planning on using the `take_1d_array` in places where I renamed `take_1d` here to `take_nd` (that would need checking of each of those cases whether they can guarantee already to be an array)
> Yes, but I am not directly planning on using the `take_1d_array` in places where I renamed `take_1d` here to `take_nd` (that would need checking of each of those cases whether they can guarantee already to be an array)

sure but its more clear now. thanks.
@jreback @jorisvandenbossche This is causing benchmarks CI to fail? 
```ImportError: cannot import name 'take_1d' from 'pandas.core.algorithms' (/home/runner/work/pandas/pandas/pandas/core/algorithms.py)```
@lithomas1 can u show where
this passed in master
I think this is it https://github.com/pandas-dev/pandas/runs/1875678358.
ahh the benchmarks 

ok - care to do a PR to fix
Whoops, sorry forgot to search/replace in the benchmarks