Deprecate inplace=True for reset_index
- [ ] xref #16529
- [ ] 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

Per the discussion yesterday, I just wanted to clarify that putting in a deprecation warning (such as thing one) in v1.3.0 gives enough time to remove `inplace` in v2.0.0 if, as is likely, there is not another minor version between v1.3.0 and v2.0.0. Will it be OK to change it to a `FutureWarning` in a patch release of v1.3?

If this is OK, then I'm running a little sprint on Saturday for PyLadiesLondon, and putting in more of these warning will make for a good sprint issue
Thanks @jreback and @phofl for your reviews, have updated accordingly

Does this seem right? If so, I'll use it as a template on Saturday and we can power through the rest of the non-controversial ones from the list > i am not sure if we can go from DeprecationWarning to FutureWarning in a patch release

That's my concern exactly, and this feels like the kind of change that would be well-suited to a major release... @jreback thoughts on this? Sorry if I missed it from the call yesterday > > i am not sure if we can go from DeprecationWarning to FutureWarning in a patch release
> 
> That's my concern exactly, and this feels like the kind of change that would be well-suited to a major release... @jreback thoughts on this? Sorry if I missed it from the call yesterday

right the purpose of showing a DeprecationWarning only rn is to give folks a long lead time & library authors to update. We would still need to flip this in a minor release, e.g. 1.4 to FutureWarning, then remove in 2.0. Clear, thanks - if the next non-patch release after 1.3 will be 2.0 in December/January, then wouldn't that give people plenty of time?

Furthermore, it's painfully common to see people ignore or even silence warnings (e.g. every other notebook on Kaggle), and so while no amount of warning will get them to update their code, seeing a major release might

I've merged master and updated to `FutureWarning` here, just to drive the conversation forwards, though of course will revert to DeprecationWarning if you prefer This one isn't on the "non-controversial" list from #16529, so perhaps it's best to close it for now and to just set its default arguments as keyword-only - would be great if we could get agreement on that, but let's take the discussion forward in #16529 I think a potential deprecation of `inplace` should be done with a DeprecationWarning first. It's widely used, so users will see a flood of warnings from libraries they wouldn't be able to do anything about themselves. 

(and also as you said, `reset_index` is not a clear candidate for deprecation, as it can potentially be done in place) Good points - closing for now then, thanks for your input!