ENH: Implement PDEP-17 #61468
ENH: Implement PDEP-17 #61468
Conversation
pandas/errors/__init__.py
Outdated
| class PandasChangeWarning(Warning): | ||
| """ | ||
| Warning raised for any an upcoming change. | ||
| """ |
There was a problem hiding this comment.
Not in love with this name, but PandasDeprecationWarning is taken below. Bikeshedding here is most welcome!
There was a problem hiding this comment.
We could also make this internal if we want to not have it be public.
rhshadrach
added
Enhancement
Warnings
|
Seems like the label |
| @@ -24,6 +24,12 @@ Enhancement1 | |||
| Enhancement2 | |||
| ^^^^^^^^^^^^ | |||
|
|
|||
| New Deprecation Policy | |||
| ^^^^^^^^^^^^^^^^^^^^^^ | |||
| pandas 3.0.0 introduces a new 3-stage deprecation policy: using ``DeprecationWarning`` initially, then switching to ``FutureWarning`` for broader visibility in the last minor version before the next major release, and then removal of the deprecated functionality in the major release. | |||
There was a problem hiding this comment.
Shouldn't we say that these could be tested via the classes PandasDeprecationWarning and PandasFutureWarning ?
| class Pandas4Warning(PandasDeprecationWarning): | ||
| """ | ||
| Warning raised for an upcoming change that will be enforced in pandas 4.0. | ||
|
|
||
| See Also | ||
| -------- | ||
| errors.Pandas4Warning : Class for deprecations to be enforced in pandas 4.0. | ||
|
|
||
| Examples | ||
| -------- | ||
| >>> pd.errors.Pandas4Warning | ||
| <class 'pandas.errors.Pandas4Warning'> | ||
| """ | ||
|
|
||
|
|
||
| class Pandas5Warning(PandasPendingDeprecationWarning): | ||
| """ | ||
| Warning raised for an upcoming change that will be enforced in pandas 5.0. | ||
|
|
||
| See Also | ||
| -------- | ||
| errors.Pandas4Warning : Class for deprecations to be enforced in pandas 4.0. | ||
|
|
||
| Examples | ||
| -------- | ||
| >>> pd.errors.Pandas5Warning | ||
| <class 'pandas.errors.Pandas5Warning'> |
There was a problem hiding this comment.
I wonder if we should have an abstract base class PandasWarning that has an abstract class method version(), and then both Pandas4Warning and Pandas5Warning inherit from that class as well, and define version() to return 4 and 5 respectively.
Then in deprecate_nonkeyword_arguments(), instead of checking for the class, you just check for version(). See comment there.
| from pandas.errors import ( | ||
| Pandas4Warning, | ||
| Pandas5Warning, | ||
| ) | ||
|
|
||
| if klass is Pandas4Warning: | ||
| version = "4.0" | ||
| elif klass is Pandas5Warning: | ||
| version = "5.0" | ||
| else: |
There was a problem hiding this comment.
If you create the ABC PandasWarning as suggested above, then you could just do
if issubclass(klass, PandasWarning):
version = klass.version()
else:
raise AssertionError(f"{type(klass)=} must be a versioned warning")| @@ -51,6 +51,12 @@ Exceptions and warnings | |||
| errors.OptionError | |||
| errors.OutOfBoundsDatetime | |||
| errors.OutOfBoundsTimedelta | |||
| errors.PandasChangeWarning | |||
| errors.Pandas4Warning | |||
| errors.Pandas5Warning | |||
There was a problem hiding this comment.
Aside from the tests, Pandas5Warning isn't used. Is the idea that we will use it in the future?
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.Continuation of #58169
Still needs tests and some cleanup with the docs and decorator arguments, but I'd like to get a first look.
cc @Dr-Irv @Aloqeely