DEPR: inplace keyword in rename
State: closed

- [ ] closes #xxxx (Replace xxxx with the Github issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Labels:
name: Deprecate
description: Functionality to remove in pandas
name: inplace
description: Relating to inplace parameter or equivalent

Comments:
> Any reason to not add the issue numbers in the PR and the whatsnew, and to not add the appropriate labels to the PR?

No, what issue numbers did you have in mind?
> No, what issue numbers did you have in mind?

This seemed to me part of #16529, I guess there is not an specific issue for `rename`. That's what I expected to see in the PR description and in the release notes. And I thought having the labels `Deprecate` and `Inplace` was quite obvious too. So, I was wondering if this was a regular PR, or if it had anything special that everything was missing.
> Has there been a recent discussion about inplace that we actually want to start doing this deprecation? (the last activity on https://github.com/pandas-dev/pandas/issues/16529 dates from a year ago-

Mostly non-documented discussions on calls from which I've gotten the impression a) some people (e.g. @jreback) feel strongly that inplace should be deprecated across the board, b) no-one is strongly pro-inplace, c) some people (mainly me i think, and I'm wavering) like inplace in the subset of cases where the operation can operate on the underlying data inplace (which is relevant mostly for e.g. fillna, replace, not things like rename).  I'm open to being corrected if this impression is inaccurate.

Also a couple months ago I saw a priorities document (which I can't find now) for the data-apis consortium that included deprecating inplace.  I'm fine with not-prioritizing their priorities if ours are different, but all else equal that makes me more in favor of "get it over with".

> Do we want to do this now? Should we try to do all deprecations / removals in a single cycle (eg that all the keywords could be removed in 2.0, or 3.0)

Users are going to have to update their code for 2.0 and again for 3.0 regardless of what we do with inplace.  I'm not inclined to worry about this.  The constraint is developer time.
> Also a couple months ago I saw a priorities document (which I can't find now) for the data-apis consortium that included deprecating inplace.

Just to be clear here (although I was involved myself): that's a document of a private meeting, and thus has no value for decision making in pandas without that those issues are also discussed on the public pandas channels. It can help for people involved there to prioritize their work, but when actually starting with that, they still need to go through the normal procedures here.

I think the impression that most core devs seem to be onboard with this change is correct (that's also my impression), but I think a good summary of the discussion in https://github.com/pandas-dev/pandas/issues/16529 would still be useful (especially because this is a change that affects _a lot_ of users, we have to communicate this change and the reasoning very well)