BrandonFors/pandas-github-issues huggingface dataset:
DEPR: df.iloc[:, foo] = bar attempt to set inplace
State: closed

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


Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Deprecate
description: Functionality to remove in pandas
name: API - Consistency
description: Internal Consistency of API/Behavior

Comments:
can you rebase
Made a couple of efforts recently to simplify the `iloc.__setitem__` and they all crash on the rocks of this inconsistency.
There's a problem here in that the `use .iloc(axis=1)[foo]=bar` won't actually work, so still need a better alternative.

But getting this done should be a very high priority for 1.5 as its a blocker for all kinds of inconsistency-fixing.
@jreback in the Feb call i think we agreed to move forward with this but there was some bikeshedding over the name of the replacement method.  Do you remember what we landed on?
> @jreback in the Feb call i think we agreed to move forward with this but there was some bikeshedding over the name of the replacement method. Do you remember what we landed on?

`isetitem` I *think*
> `isetitem` I think

cool, since thats what the PR implements ATM
@jreback gentle ping, finally green
thanks @jbrockmendel yeah has been out here for a while :->

followup, i think we need `.isetitem` in the api docs (and maybe a mention in the indexing.rst as well)
TYP: offsets.pyi
State: closed

This PR and #44922 are the last parts of #43744.

Labels:
name: Typing
description: type annotations, mypy/pyright type checking

Comments:
Hello @twoertwein! 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 2022-02-17 03:27:46 UTC
cc @simonjayhawkins 
@twoertwein can you merge main


@jbrockmendel rebased and green
@twoertwein status here?
> @twoertwein status here?

I think it should be ready. The open two comments would require non-typing changes, which I would like to avoid in this PR.
thanks @twoertwein 
hmm maybe should have rebase first, oh well, let's see
DOC: fix a typo
State: closed

"based or their" -> "based on their"

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [ ] whatsnew entry


Labels:
name: Docs

Comments:
Thanks @partev
CI: Fix concurrency group for min versions posix builds
State: closed

- [x] tests added / passed

In the effort of sharing more dependency yaml files, the concurrency group definition will need to change since separate builds won't be unique on these yaml files anymore

Labels:
name: CI
description: Continuous Integration

Comments:
@meeseeksdev backport 1.4.x
Can't Dooooo.... It seem like this is already backported (commit is empty).I won't do anything. MrMeeseeks out.
DEPR: Series/DataFrame/HDFStore.iteritems()
State: closed

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


Labels:
name: IO HDF5
description: read_hdf, HDFStore
name: Deprecate
description: Functionality to remove in pandas

Comments:
What's the reasoning to deprecate `iteritems()`? 

I suppose it is the duplication with `items()`? On the other hand, `iteritems()` also gives some consistency with `iterrows` and `itertuples`, which could be a reason in favor to rather keep `iteritems()`?
The duplication with `items()` was the motivation.

I think `iteritems()` was designed to mirror Python's dict API in 2.7, and since that was removed in PY3 I chose to remove `iteritems()`. (I encountered evidence of this when I tried deprecating `Series/DataFrame.keys`, and an internal path was flexibly accepting a dict-like API)




> when I tried deprecating `Series/DataFrame.keys`

Do you still have plans to propose that? Or the problems you encountered were sufficient to drop the idea? 
(if we would like to deprecate `.keys()` (I personally never use it), that would be another reason to keep `iteritems()`, I would say)
Yeah it was tricky to deprecate `keys()` since:

```
In [3]: pd.core.dtypes.inference.is_dict_like(Series([1]))
Out[3]: True

In [4]: pd.core.dtypes.inference.is_dict_like(DataFrame([1]))
Out[4]: True
```

in which `keys` is an attribute `is_dict_like` checks. So it may be API breaking / a lot of effort if keys were deprecated.
-1 on interitems this deprecated in python itself
ENH: Add allow_duplicates to MultiIndex.to_frame
State: closed

- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry

Part of issue #45245 for multi-indexes with repeated level names.

Old behavior was to remove columns with repeated level names:

```
import pandas as pd
pd.MultiIndex.from_tuples([[1, 2]], names=["a", "a"]).to_frame()
     a
a a   
1 2  2
```

New behavior is to raise, unless `allow_duplicates` is `True`:

```
pd.MultiIndex.from_tuples([[1, 2]], names=["a", "a"]).to_frame(allow_duplicates=True)
     a  a
a a      
1 2  1  2
```

Note: The other issues in #45245
1. Missing column names. This has been left as it was:  the name is filled with the level number, n. This is different from many other methods that fill with level_n, but obviously needs discussing.
2. bool values: might be fixed by #45061 

Labels:
name: Enhancement
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode

Comments:
Hello @johnzangwill! 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 2022-01-20 11:35:58 UTC
I have factored out a private Index._make_labels. It is just used in Index and MI to_frame (see my note above https://github.com/pandas-dev/pandas/pull/45318#discussion_r786047914)

A tiny change of behavior would be e.g. Index([0], name="") which would have been changed to 0 before. Now it is left as "" because I am looking for explicit None, rather than just Falsey.

The tests all seem to pass.
This is as Green as CI allows...
@jreback Please see my note (https://github.com/pandas-dev/pandas/pull/44755#discussion_r786120819) . I think that you will find that my solution there is not so bad as you first thought.
thanks @johnzangwill
BUG/ENH: Translate CSS border properties for `Styler.to_excel`
State: closed

- [x] checks an item on #42276 ("Border styles bug")
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry


Labels:
name: IO Excel
description: read_excel, to_excel
name: Styler
description: conditional formatting using DataFrame.style

Comments:
Hello @tehunter! 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 2022-02-10 13:27:41 UTC
@github-actions pre-commit
Any idea what could be causing the failure? It's something related to filesystems in `test_arrowparquet_options`, which I haven't touched.
Looking really good, especially the style round trip. Just one or two comments for optimisation.
@github-actions pre-commit
needs a whats new 1.5.0, (maybe 1.4.1 if it can be backported).

Otherwise looks good to me, pending we get green tests.

Note that you could have considered using a pattern like:
```
expand_border_left = functools.partial(_border_expander, str="left")
```
and you wouldn't have needed to code your own function wrapper for border expand.


> can you show a test that exerices this at a high level as well

Its difficult to test this since you have to write to excel and then read that the file rendered correctly.

The round trip tests I requested in `test_style.py` now do this: explicitly they check that:

a) The styled dataframe (with a border) is different to the unstyled dataframe (without border)
b) that the excel file created is read in correctly by openpyxl and has the border styles as expected.
> needs a whats new 1.5.0, (maybe 1.4.1 if it can be backported).

Do I write the entry or does a maintainer do that? I propose 2 entries along the lines of:

- Bug Fix: Fixed bug in `CSSToExcelConverter` leading to `TypeError` when border color provided without border style for `xlsxwriter` engine (GH42276)
- Enhancement / Styler Enhancements: Added the ability to render `border` and `border-{side}` CSS properties in Excel (GH42276)
@tehunter u add them
looks fine (but before i resolved i think the doc-build was failing) so let's check that.
yeah these are failing: https://github.com/pandas-dev/pandas/runs/4841791532?check_suite_focus=true
@github-actions pre-commit
@tehunter if you get a chance to merge with main, i can take a look at the CI errors you are getting
thanks @tehunter
BUG: Float64Index.astype('u8') returns Int64Index
State: closed

- [x] closes #45151
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry

We _could_ deprecate the casting instead of raising.  Or could decide we're OK allowing it I guess.

Labels:
name: Bug
name: Index
description: Related to the Index class or subclasses
name: Astype

Comments:
this is fine
Backport PR #45244 on branch 1.4.x (TYP: Ignore numpy related issues)
State: closed

cc @jreback

Backport PR #45244

Labels:
name: Typing
description: type annotations, mypy/pyright type checking

Comments:
> pandas/core/dtypes/cast.py:1127: error: Unused "type: ignore" comment
pandas/core/dtypes/cast.py:1148: error: Unused "type: ignore" comment
Thx, fixed
BUG: hash_array TypeError instead of AttributeError on Index GH#42003
State: closed

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


Labels:
name: Bug

Comments:
updated + greenish
prob worth a whatsnew note as well here (followon fine)
REF: fewer simple_new calls in DTA._generate_range GH#24562
State: closed

- [x] closes #24562
- [ ] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [ ] whatsnew entry

The _simple_new calls are cheaper than they were back then, so we won't see that much improvement.  Still should be better than nothing.


Labels:
name: Refactor
description: Internal refactoring of code
name: Datetime
description: Datetime data dtype
name: Performance
description: Memory or execution speed performance

Comments:
great
BUG: setitem into complex64 overflow
State: closed

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


Labels:
name: Bug
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Complex
description: Complex Numbers

Comments:
can you rebsae
rebased + greenish
BUG: do not replace all nulls with "NaN"-string in Series index
State: closed

- [x] closes #45263, #45222
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry

After this, the example 

```
import pandas as pd
import numpy as np

s=pd.Series([1,2,3,4], [True, None, np.nan, pd.NaT])

print(s)
```

yields 

```
True    1
None    2
nan     3
NaT     4
dtype: int64
```

which is good.

I've kept the behavioral changes minimal, however not sure it is the best way to go.

1) `SeriesFormatter` has a `na_rep` (https://github.com/pandas-dev/pandas/blob/b77797cde57969b3ee14d961f4dacd5cab25cb61/pandas/io/formats/format.py#L280) but it is not used for index-formating (I use `None` to signal that I don't want any replacing). But why should values be handled differently?

2. Why does is make sense to replace nans with na_repr in the index in the first place? See https://github.com/pandas-dev/pandas/blob/b77797cde57969b3ee14d961f4dacd5cab25cb61/pandas/core/indexes/base.py#L1392-L1411




Labels:
name: Missing-data
description: np.nan, pd.NaT, pd.NA, dropna, isnull, interpolate
name: Output-Formatting
description: __repr__ of pandas objects, to_string

Comments:
Hello @realead! 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 2022-01-19 07:01:19 UTC
This is the commit where special handling for the null-objects was added: in #https://github.com/pandas-dev/pandas/pull/3034 with https://github.com/pandas-dev/pandas/commit/aae62135fe7f795c6218de432e9409d25d02e627
The question is what to do about DataFrame?

```
import pandas as pd
import numpy as np
s=pd.DataFrame([1, 2, 3, 4], [True, None, np.nan, pd.NaT])
print(s)
```
leads to 

```
      0
True  1
NaN   2
NaN   3
NaN   4
```

It probably should behave the same way Series behaves?
yes
After the change np.nan is printed as "nan". Probably we would like to keep "NaN"?
How can we access values where index is NaN??
s[NaN] 
s[pd.NaT]
results in an error
Traceback (most recent call last):
  File "<pyshell#16>", line 1, in <module>
    s[NaN]
NameError: name 'NaN' is not defined

@realead can you merge master. we fixed the doc links there so let's see
@jreback  it seems to work now.
BUG: pd.to_datetime([np.str_ objects]) GH#32264
State: closed

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


Labels:
name: Datetime
description: Datetime data dtype

Comments:
yeah agree we likley need a generic conversion function where we can use everywhere we accept strings
Fix groupby any/all on an empty series/frame
State: closed

- [x] closes #45231
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them

Confirmed this issue did not exist on 1.3.x, so no whatsnew entry necessary.

Labels:
name: Bug
name: Groupby

Comments:
@meeseeksdev backport 1.4.x
thanks @rhshadrach 
Something went wrong ... Please have a look at my logs.
BUG: can_hold_element size checks on ints/floats
State: closed

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


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

Comments:
prob needs a whatsnew
BUG: DataFrame.astype preserve subclasses GH#40810
State: closed

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


Labels:
name: Bug
name: Subclassing
description: Subclassing pandas objects

Comments:
greenish
DOC: improving example
State: closed

- [x] closes #45222

This is a minimal fix: the example with strange output is replaced (even if the underlying problem is not fixed/should be fixed)

Now the output in the current version is:

```
Index([None, NaT, True], dtype='object')
```




Labels:
name: Output-Formatting
description: __repr__ of pandas objects, to_string

Comments:
@jreback I've proposed a fix for repr-issue in #45283. Not sure it is good to make such a change  shortly before release (and thus this much more minimal PR) also probably some discussion needed  what is actually the desired and consistent behavior (probably not only series are affected).
closing in favor of #45283 
> @jreback I've proposed a fix for repr-issue in #45283. Not sure it is good to make such a change shortly before release (and thus this much more minimal PR) also probably some discussion needed what is actually the desired and consistent behavior (probably not only series are affected).

yeah i think your change is fine
Added note in docs for giving the developer the option of choosing be…
State: closed

…tween both parameters and kwargs. Exampled included

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [ ] whatsnew entry


Labels:
name: Docs
name: Timedelta
description: Timedelta data type

Comments:
thanks @Pydare 
@meeseeksdev backport 1.4.x
Something went wrong ... Please have a look at my logs.
this closes #45258?
yep
CI: Simplify GHA dependency files
State: closed

- [x] tests added / passed

Progress towards #29685

Just creates `actions-38.yaml` and `actions-39.yaml` with all required and optional dependencies, unpinned with the same existing builds

Labels:
name: CI
description: Continuous Integration

Comments:
thanks @mroeschke possibly need to rebase other PRs which hit the CI configs as well

cc @lithomas1 
@meeseeksdev backport 1.4.x
Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 1.4.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -m1 f2a0125663bbcf8701347c00329c311e7391608e
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #45257: CI: Simplify GHA dependency files'
```

4. Push to a named branch:

```
git push YOURFORK 1.4.x:auto-backport-of-pr-45257-on-1.4.x
```

5. Create a PR against branch 1.4.x, I would have named this PR:

> "Backport PR #45257 on branch 1.4.x (CI: Simplify GHA dependency files)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
It appears that most of the changes here were included in #45464 except for the changes to ci/deps/actions-39.yaml
ENH: Index[complex]
State: closed

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


Labels:
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: Index
description: Related to the Index class or subclasses

Comments:
looks ok for 1.4? can you rebase
> looks ok for 1.4?

id rather not rush this.
uh probably premature.  among other things needs whatsnew
ok sure
BUG/PERF: MaskedArray.searchsorted(np.nan)
State: closed

Needed for follow-up to ExtensionIndex to avoid object-dtype cast for engine.

```
arr = pd.array(range(10**5))

%timeit arr.searchsorted(4)
2.87 ms ± 223 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
6.67 µs ± 178 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```

Labels:
name: Performance
description: Memory or execution speed performance
name: NA - MaskedArrays
description: Related to pd.NA and nullable extension arrays

Comments:
>  # The base class casts to object dtype, for which searchsorted returns
        #  0 from the left and 10 from the right.

i think needs a whatsnew? as this is the bug right
PERF: find_stack_level
State: closed

- [ ] closes #45099
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [ ] whatsnew entry

Some low hanging fruit in find_stack_level. 
``pytest pandas/tests/groupby/test_function.py -v -k "test_builtins_apply"`` goes from 35 -> 6 secs for me.
Someone may want to verify. Also IDK how to benchmark this.

@jbrockmendel Would you like to test this locally to verify the perf gains?

Labels:
name: Performance
description: Memory or execution speed performance

Comments:
> Would you like to test this locally to verify the perf gains?

I'm happy to take your word for it.
@mroeschke good here?
thanks @lithomas1 
wouldn't object to backport ing this
@meeseeksdev backport 1.4.x
TYP: Ignore numpy related issues
State: closed

- [x] xref #45182
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry

This worked for me locally

Labels:
name: Typing
description: type annotations, mypy/pyright type checking

Comments:
Hello @phofl! 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 2022-01-07 13:25:05 UTC
@phofl i think i merged some things, can you merge master and ping when ready
Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 1.4.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -m1 d603d43df2057ecdf74010d9dadc735e37f8f7b5
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #45244: TYP: Ignore numpy related issues'
```

4. Push to a named branch:

```
git push YOURFORK 1.4.x:auto-backport-of-pr-45244-on-1.4.x
```

5. Create a PR against branch 1.4.x, I would have named this PR:

> "Backport PR #45244 on branch 1.4.x (TYP: Ignore numpy related issues)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
thanks @phofl hopefully this should backport
hmm i guess not, if you can push a manula backport @phofl 
Will try to setup a pr in the evening