PEP 594, take 2: Removing dead batteries from the standard library

PEPs
7

I suggest skipping PendingDeprecationWarning and going directly to DeprecationWarning.

Even with DeprecationWarning, it’s been a problem that warnings aren’t heeded or seen, and more than once removals have been bumped to a later release.

For example, using collections.Mapping instead of collections.abc.Mapping emitted a DeprecationWarning since Python 3.3 and was set to be removed in 3.9 but was bumped to 3.10 (and also to allow projects to drop 2.7 in concert).

https://docs.python.org/3/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

More recently, some unittest removals (deprecated since 3.5) and configparser (since 3.2) were reverted from 3.11 and deferred until 3.12.

https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911/7?u=hugovk

I also recommend mentioning in the warning which Python version removal is expected. This means people who see the warning have a visible timetable to work towards, rather than some vague point in the future.

PEP 387:

  1. Add a warning. If behavior is changing, the API may gain a new function or method to perform the new behavior; old usage should raise the warning. If an API is being removed, simply warn whenever it is entered. DeprecationWarning is the usual warning category to use, but PendingDeprecationWarning may be used in special cases where the old and new versions of the API will coexist for many releases [2]. Compiler warnings are also acceptable. The warning message should include the release the incompatibility is expected to become the default and a link to an issue that users can post feedback to.
2 Likes