BrandonFors/pandas-github-issues huggingface dataset:
ENH: Deprecate arguments #41485
State: closed

- [ ] xref #41485 
- [ ] 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: IO CSV
description: read_csv, to_csv
name: Deprecate
description: Functionality to remove in pandas

Comments:
Hello @Anupam-USP! 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-05-27 12:58:55 UTC
@Anupam-USP pls rebase & fix this up; ping when ready for a look.
> @Anupam-USP pls rebase & fix this up; ping when ready for a look.

Yes I am woking on it, but haven't got any conclusive solutions. Can you please help me?

@jreback I added the milestone since I think we want to get all these deprecations in at the same time?
@simonjayhawkins i understand but this one is not ready
@MarcoGorelli can you help push this over the line.
Is there anything I can do to resolve the issue?

> Yes I am woking on it, but haven't got any conclusive solutions. Can you please help me?

what is the issue? do the ci logs not help?
I am new to the ci logs and not able to find the solution of the them. Can you help me?

Hey @Anupam-USP - no worries, I've added a commit this time fixing it up due to time constraints, next time I'll help out
Okay @MarcoGorelli ! Though I wasn't fully able to resolve this issue but this was my very first PR. Thank you
@Anupam-USP FYI: next time create a feature branch for the changes. https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#creating-a-branch
Thanks @Anupam-USP for having started this one - if you look at what's been changed and try resample.interpolate then I think we can get that one in too
Hi @MarcoGorelli @simonjayhawkins, 
It looks like this is only done for ``read_csv``, but it would probably be better if this were also done for ``read_table`` too, given that they are pretty much the same function. (Also, would it possible to add this to the deprecation log (#30228) where the deprecations are tracked?)
Thanks
I can try it, if it is available @simonjayhawkins @MarcoGorelli 
I think that's a good suggestion, thanks @lithomas1 ! Any others you think of, can you add them to #41657?
BUG: groupby.transform/agg caching *args with numba engine
State: closed

- [x] closes #41647
- [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: numba
description: numba-accelerated operations

Comments:
thanks @mroeschke
API: EA._can_hold_na -> EDtype.can_hold_na
State: closed

- [x] closes #40574
- [ ] 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: API Design
name: Blocker
description: Blocking issue or pull request for an upcoming release
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
> pandas/tests/extension/test_external_block.py:18: error: Cannot override final attribute "_can_hold_na" (previously declared in base class "Block")  [misc]

actually this is failing precommit
pre-commit fixed
I know this is an existing property on the ExtensionArray, but do we actually support (or want to support) an extension array that cannot hold missing values? (I don't think we currently have one, so this is also not really tested?)
> I don't think we currently have one

Except for PandasArray, I assume (but since that's not actually stored in practice, that's a bit a special case anyhow)
I think `Sparse[inty]`?
i've added blocker since I don't think we should change this during the rc. so we either get it in for 1.3.0rc or move to 1.4/2.0
is the public/private question (and a rebase) the only outstanding issue?  im happy to make this private
Also the question whether we should have this at all, IMO. And if we have that property, what does it mean? (what's the behaviour for operations like setitem or reindexing that can introduce missing values?)
> Also the question whether we should have this at all, IMO. And if we have that property, what does it mean? (what's the behaviour for operations like setitem or reindexing that can introduce missing values?)

I'm open to having this discussion, but I think it can be done separately from the "where should this attribute live" discussion given that it already exists on EA.
But if we are not yet sure if and how such property would be used, we can also leave it where it is for now? (or what problem is this PR fixing?)

If moving it, let's at least make it private and document it that way (as an internal property that no EA author should change, as that is undefined behaviour)
> (or what problem is this PR fixing?)

The corner cases I want to rule out are where can_hold_na is values-dependent and potentially non-constant, e.g. (xref #40574)

```
class WeirdEA(ExtensionArray):
      @property
      def _can_hold_na(self) -> bool:
           return some_func(self[0])
```
this lgtm, i agree this should be on the dtype.
@jorisvandenbossche ok here?
Yeah, I won't object moving it. Just a tiny comment on the whatsnew.
whatsnew removed + greenish
Thanks @jbrockmendel
FMT: trim redundant freqstr from PeriodIndex __repr__
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: Output-Formatting
description: __repr__ of pandas objects, to_string
name: Period
description: Period data type
name: Index
description: Related to the Index class or subclasses

Comments:
Thanks @jbrockmendel release note?
REF: standardize astype in EA subclasses
State: closed


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

Comments:
Thanks @jbrockmendel, by changing the accepted types for astype we are changing the api for 3rd party EAs. probably needs a release note. (subclassed EA need to accept the same types as the base class) cc @Dr-Irv if any comments



> Thanks @jbrockmendel, by changing the accepted types for astype we are changing the api for 3rd party EAs. probably needs a release note. (subclassed EA need to accept the same types as the base class) cc @Dr-Irv if any comments

IMHO, I think you ought to first accept/merge in #41251 where I created overloads for `astype` in various subclasses to separate out the cases of using a base type versus a numpy dtype, and then merge in this one.

I think there is a separate issue of how we should handle `astype(extension_dtype)` for crossing between extension dtypes and regular types, and vice versa, which I think this PR is trying to address.

ill just revert the type annotation
Mothballing since i cant replicate the failures locally.
GH41457 Upgrade Bootstrap to v5.0
State: closed

Whats new:

Update BS script tags in template

Replace jumbotron with utilities

Replace font-weight-bold with fw-bold

Replace ml-auto with ms-auto

Replace float-right with float-end

Replace data-target with data-bs-target

Replace data-toggle with data-bs-toggle

Add CSS rules for <a>

- [x] closes #41457 
- [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: Web
description: pandas website

Comments:
Live preview [here](https://adoring-swanson-8508a0.netlify.app/)
I have the build folder too in case anyone wants to double check locally without pulling the branch.
[build.zip](https://github.com/pandas-dev/pandas/files/6535371/build.zip)

Thank you @datapythonista! I am sorry this may be a dumb question, but do you mean I should merge with the latest master so that the CI will pass? If so, should I be doing merge (fast-forward) or rebase?
Your branch was created two weeks ago, so your changes (the diff in this PR) are proposed on that old `master`. That master was broken for some problems with the development branch of numpy, that's why the CI is red.

So, the idea is that you updated your branch, so it contains all the changes in master for the last two weeks. The CI should be then green, and also, if anything changed in master that affects this PR, we should have it in the diff and in the CI.

In practice, that's simply `git fetch upstream`, and then `git merge upstream/master` being in your branch. And then you `git push` to update this PR.

Does it make sense?
@datapythonista I need some help, I merged master but some CI checks are still failing. Should I merge again with the latest master and try again? Thank you in advance.
I can't check in detail now, but seems like all last PRs are red, so I guess something is broken in master. You'll have to wait until it's fixed, and thrn merge master again.
@datapythonista thought I'd try again after merging with the latest master, but still no luck :(

The error from one of the failing check occurs when running the bash script to create the conda environment

`("Connection broken: ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None)", ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))`

I wonder what I can do to fix this problem?
Let's rerun and see, seems like conda servers are having problems recently.
Thank you!

All the tests passed except one. Looks like an issue with one of the `scalar/timedelta` tests. There is currently a PR to fix it (#42413). Once that is merged to master I will merge and push again.
@datapythonista all the tests passed. Thank you for your guidance and assistance!
thanks @calvh
Deprecated nonkeyword arguments for set_codes function
State: closed

- [ ] xref #41485
- [ ] 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: Deprecate
description: Functionality to remove in pandas

Comments:
Hello @Pydare! 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-05-27 13:21:34 UTC
this is failing some precommit tests, pls rebase and fix up.
thanks @Pydare
Documentation: Indexing and selecting data¶
State: closed

fixes #41629 

Hi @LukeTonin, how does this look?
let me know if this needs any changes!
Thanks


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

Comments:
Just commenting that medium.com is a paid article provider. That link is not always available, depending upon how many "free" articles you are permitted view in a period of time.
Maybe can be added this https://stackoverflow.com/a/41130329/10491422 due it's a common limitation that causes confusion, instead of a medium blog 
Sure! I can do that 
@rbrishabh That looks good. Agreed with the point about medium not always being accessible. A "free" resource would be better.
Thanks! @LukeTonin made that `url` change
can u make this into a :note: to make this more prominent

text looks good

ping when greenish
There is already a [warning block](https://github.com/pandas-dev/pandas/pull/41645/files#diff-faa1b06767c38c506752127df49ec52fb61d6d9a0ad834ffd6fb24618035e070R207-R219) with this information in the same section; wouldn't a note linking out to an external resource be redundant?

Also, after changing what the link goes to, the context ("10 reasons") no longer corresponds.
yeah i see this is already adequately documented: https://pandas.pydata.org/pandas-docs/dev/user_guide/indexing.html#attribute-access, thanks @mwaskom 

thanks for the effort @rbrishabh
BUG: Series[int].loc setitem with Series[int] results in Series[float]
State: closed

```
>>> pd.__version__
'1.3.0.dev0+1695.g55e58542db'
>>> 
>>> s = pd.Series([0, 0])
>>> s
0    0
1    0
dtype: int64
>>> 
>>> s2 = pd.Series([42])
>>> s2
0    42
dtype: int64
>>> 
>>> s.loc[0] = s2
>>> s
0    42.0
1     0.0
dtype: float64
>>> 
```

Does not need a release note, this issue is only on master as on 1.2.4 this raises `ValueError: No axis named 1 for object type Series` which was fixed in #39358

draft, since if we merge and backport #40555 first, we can also remove the patch in this PR.

Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: Series
description: Series data structure

Comments:
milestoned as 1.3, but if the indexing is to be changed in another PR this becomes less urgent.
let's move off the milestone
No what's new needed. Only changes master.

On Fri, 4 Jun 2021, 21:29 Jeff Reback, ***@***.***> wrote:

> ***@***.**** requested changes on this pull request.
>
> can you add whatsnew
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/41644#pullrequestreview-676641769>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADEMUXI7MC47NEW25ZF47KLTREZRTANCNFSM45NOJ7QQ>
> .
>

LGTM
@jreback OK to merge?
yep
REF: share __array_wrap__
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: Refactor
description: Internal refactoring of code
name: Compat
description: pandas objects compatability with Numpy or Python functions

Comments:
nice!
CLN: remove unused _max_fitting_element
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: Clean
name: Index
description: Related to the Index class or subclasses

Comments:
Thanks @jbrockmendel
CLN: remove unnecessary _comparables
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: Clean
name: Index
description: Related to the Index class or subclasses

Comments:
looks good can u rebase and merge in green
CI: Unpin pip in py38 npdev
State: closed

- [x] closes #38221
- [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: CI
description: Continuous Integration
name: Dependencies
description: Required and optional dependencies

Comments:
Current CI failures are #41632(unrelated).
Thanks @lithomas1
ENH: set render limits on `Styler` to automatically trim dataframes
State: closed

- [x] closes #40712  also linking #11700
- [x] tests added / passed

Adds an option: `styler.max.elements` with a default value of 2**18 = 262144.

```
>>> pd.options.styler.max.elements = 2**18
>>> df = pd.DataFrame(np.random.rand(10000,100))
>>> %timeit df.style.render()
4.11 s ± 30.3 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
```
Even though this is a *'large'* dataframe it is reduced to the max elements and still renders in reasonable time (4s plus about 5s for a browser to render the date).

If the number of data elements exceeds the max then the right side, or bottom, or both of the DataFrame will be trimmed (starting with the largest axis and recursively reducing), leaving '...' filler indicators.

All reduction takes place before index or data looping so it avoids any crashes.

![Screen Shot 2021-05-23 at 20 44 15](https://user-images.githubusercontent.com/24256554/119274105-975dc100-bc0e-11eb-9ac4-8df45ceb0d0d.png)





Labels:
name: Bug
name: Enhancement
name: Styler
description: conditional formatting using DataFrame.style

Comments:
thanks @attack68
REF: convert_dtypes return dtype objects
State: closed

This turns out to be a blocker for sharing arrays.integers.safe_cast with maybe_cast_to_integer_array, which in turn is a blocker for #34460

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

Comments:
> Thanks @jbrockmendel lgtm cc @Dr-Irv if any comments.

lgtm
Thanks @jbrockmendel
TYP: NaTType comparisons
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: Typing
description: type annotations, mypy/pyright type checking

Comments:
Thanks @jbrockmendel
REF: type change `escape` in `Styler.format` to str to allow "html" and "latex"
State: closed

Change is made ahead of 1.3.0 to pre-empt the addition of `escape_latex` and to avoid name ambiguity.

This is not user facing since the `escape` kwarg was added for 1.3.0 only recently.

**Alternative**

If instead of having separate `escape_html` and `escape_latex` kwargs we could have `escape={None, 'html', 'latex'}` since it is likely they will be used exclusively??

Labels:
name: Refactor
description: Internal refactoring of code
name: Styler
description: conditional formatting using DataFrame.style

Comments:
> can u move this to the to_html or to_latex method instead?

no, because it's mixed in as part of the formatting routine, and the idea is that DataFrames should be formatted before calling `to_html` or `to_latex`, i.e.

```df.style.format(...).to_xxx()```

if escape is added to the render method then `format` needs to be called within the render method overwriting the previous chained application and negating it all and restricting its flexibility.

what about expanding the keyword inputs to:

```
escape=None,
escape='html'
escape='latex'
escape=['html', 'latex']
```

?





yeah the last is fine i guess

but is there a way to just escape things that work in both html and latex?
> yeah the last is fine i guess
> 
> but is there a way to just escape things that work in both html and latex?

not currently because of operation order. the format method is ignorant of how the styler will ultimately be rendered, and it yields a one-arg-callable for each data element decoupled from render method. if it becomes dependent it introduces operation order complexity and possible performance degradation. 

(and of course html and latex have different escaped chars)

will propose the former alternative and can review again.
@jreback it turns out some of the escaped characters overlap so it is **impossible** to escape 'html' and 'latex' simultaneously.

I've edited this PR to allow `escape in {None, 'html', 'latex'}` and added the necessary latex escape function and tests.
CLN: various related to numeric indexes
State: closed

A few bits to make #41153 smaller.

Also fixes an issue with the current implementation of NumericIndex._engine_type:

The implementation currently uses `self.dtype.type`, which is a problem when we are given platform-specific dtypes, e.g. `np.intc`.

For example:

```python
>>> d1 = np.dtype(np.intc)
>>> d1
dtype('int32')
>>> d2 = np.dtype(np.int32)
>>> d1 == d2
True
>>> d1.type == d2.type
False  # a problem
```

So the _engine_type dict should use np.dtype(np.int64) etc., so avoid such problems.

Labels:
name: Clean
name: Index
description: Related to the Index class or subclasses

Comments:
Ping? 

Np.dtype("Int64") doesn’t raise, so I do think using pandas_dtype + asserting a numpy dtype is better than np.dtype.
thanks @topper-123
REGR: CategoricalIndex(None)
State: closed

- [x] closes #38944
- [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: Categorical
description: Categorical Data Type
name: Deprecate
description: Functionality to remove in pandas
name: Index
description: Related to the Index class or subclasses

Comments:
whatsnew note added, tests edited per suggestion
Thanks @jbrockmendel
TYP deprecate_nonkeyword_arguments
State: closed

If we have
```python
import pandas as pd

reveal_type(pd.Series(range(3)).interpolate('linear'))
```

then on master we get:
```console
$ mypy t.py 
t.py:3: note: Revealed type is 'Any'
```
while here
```console
$ mypy t.py 
t.py:3: note: Revealed type is 'Union[pandas.core.series.Series, None]'
```

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

Comments:
thanks @MarcoGorelli
TST: Old issues
State: closed

- [x] closes #15452
- [x] closes #15613
- [x] closes #15829
- [x] closes #15891
- [x] closes #15898
- [x] closes #16018
- [x] closes #16174
- [x] closes #16309
- [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



Labels:
name: Testing
description: pandas testing functions or related to the test suite

Comments:
i think some of the failures are real
> I think some of the failures are real

Looks like just the normal flaky compression error and the new npdev failures
yep thanks @mroeschke
[ArrowStringArray] TST/CLN: cleanup str.replace tests
State: closed

pre-cursor to #41590

Labels:
name: Testing
description: pandas testing functions or related to the test suite
name: Clean

Comments:
Hello @simonjayhawkins! 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-05-21 10:53:20 UTC
BUG: DataFrame(ndarray[dt64], dtype=object)
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
- [x] whatsnew entry


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

Comments:
does this need a release note. maybe open a issue too.
yeah not even sure what its' actually fixing :->
whatsnew added + green