For me, deprecated functions cause me a lot of thinking when I met them as a Python maintainer and as a Python user. Why is it still there? What is its purpose? Is there a better alternative? It's related to the Chesterton's fence principle. Sometimes, reading the doc is enough. Sometimes, I have to dig into the bug tracker and the Git history. In Python, usually, there is a better alternative. A recent example is the asyncore module that I'm proposing to remove. This module has multiple design flaws which cause bugs in corner cases. It's somehow dangerous to use this module. Deprecating the module doesn't help users who continue to use it and may get bugs in production. Removing the module forces user to think about why they chose asyncore and if they can switch to a better alternative. It's supposed to help users to avoid bugs. The gray area is more about "deprecated aliases" and having two ways to do the same things, but one way is deprecated. One example is the removal of collections.MutableMapping: you must now use collections.abc.MutableMapping. Another example is the removal the "U" mode in the open() function: the flag was simply ignored since Python 3.0. So far, the trend is to remove these "aliases" and force users to upgrade this code. Not removing these aliases has been discussed, and it seems like each time, it was decided to remove them. Usually, the "old way" is deprecated for many Python versions, like 5 years if not longer. Using deprecated functions is a threat in terms of technical debt. An application using multiple deprecated functions will break with a future Python version. It's safe to avoid deprecated functions whenever possible. Some deprecated functions have been removed but then restored for 1 or 2 more Python releases, to give more time to users to upgrade their code. At the end, the deprecated code is removed. We can warn developers to pay attention to DeprecationWarning warnings, but sadly, in my experience, the removal is the only trigger which works for everybody. Do you have to repeat "You should check for DeprecationWarning in your code" in every "What's New in Python X.Y?" document? Python 3.9 has such section: https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecati... Victor On Fri, Nov 12, 2021 at 11:58 AM Petr Viktorin <encukou@gmail.com> wrote:
We're rebuilding many popular projects with Python 3.11 alpha, and I see many failures like:
AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'? (bpo-45173)
ImportError: cannot import name 'formatargspec' from 'inspect' (bpo-45320)
AttributeError: '[...]Tests' object has no attribute 'failUnless' (bpo-45162)
Are these changes necessary? Does it really cost us that much in maintainer effort to keep a well-tested backwards compatibility alias name, or a function that has a better alternative?
I think that rather than helping our users, changes like these are making Python projects painful to maintain. If we remove them to make Python easier for us to develop, is it now actually that much easier to maitain?
The current backwards compatibility policy (PEP 387) sets a *minimum* timeline for deprecations and removals -- "deprecation period must last at least two years." But it seems like it's not treated as a minimum: if any contributor sends an issue/PR to remove deprecated functionality, it's merged without much discussion. And it's very easy to "solve" these "issues", since everything is already marked for deletion; I fear we get the same kind of bikeshed/powerplant problem https://bikeshed.com/ for changes that explains for discussion. It's just so much easier to do "spring cleaning" than solve other problems.
Note that I am criticizing the *process*; the examples I gave have some people's names attached, and I have no doubt the people acted with best intentions. I'm also not talking about code that's buggy, insecure, or genuinely hard to maintain.
If deprecation now means "we've come up with a new way to do things, and you have two years to switch", can we have something else that means "there's now a better way to do things; the old way is a bit worse but continues to work as before"?
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYJOQL36... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.