Are we ready to start cleaning up deprecated stuff?
Python 3.9 is going to be the first release which will exist without any Python 2.7 overlap. Does this mean we are ready to start removing things that have been deprecated since at least Python 3.7? PEP 4 says [we are in the clear for modules](https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-pytho...), but I figured I would double-check as questions of cleaning up individual functions that have been deprecated for a very long time are now starting to come up (e.g. https://bugs.python.org/issue38916).
On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon
Python 3.9 is going to be the first release which will exist without any Python 2.7 overlap. Does this mean we are ready to start removing things that have been deprecated since at least Python 3.7? PEP 4 says [we are in the clear for modules]( https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-pytho...), but I figured I would double-check as questions of cleaning up individual functions that have been deprecated for a very long time are now starting to come up (e.g. https://bugs.python.org/issue38916).
If it has been through a usual deprecation cycle (in the past that was two releases... with 3.9's now accelerated schedule does it count as a full release for that purpose? if not, three releases is always good) it seems fair to consider removal. The only thing that would make me say "hold off" on a specific removal is if removing it will cause pain for people still dealing with a mixed 2.7 and 3.x codebase. ie: If it is an old API from the 2.x era and there is no easy way to accomplish the equivalent of that deprecation in 2.7 and 3.9+ without contortions I'd hold it just a little longer, until 3.10 or 3.11, unless the existence of the deprecated thing is a large maintenance burden rather than just an annoyance. -gps
Gregory P. Smith wrote:
On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon brett@python.org wrote:
Python 3.9 is going to be the first release which will exist without any Python 2.7 overlap. Does this mean we are ready to start removing things that have been deprecated since at least Python 3.7? PEP 4 says we are in the clear for modules, but I figured I would double-check as questions of cleaning up individual functions that have been deprecated for a very long time are now starting to come up (e.g. https://bugs.python.org/issue38916). If it has been through a usual deprecation cycle (in the past that was two releases... with 3.9's now accelerated schedule does it count as a full release for that purpose? if not, three releases is always good) it seems fair to consider removal. The only thing that would make me say "hold off" on a specific removal is if removing it will cause pain for people still dealing with a mixed 2.7 and 3.x codebase. ie: If it is an old API from the 2.x era and there is no easy way to accomplish the equivalent of that deprecation in 2.7 and 3.9+ without contortions I'd hold it just a little longer, until 3.10 or 3.11,
But what's an acceptable contortion? Some might say something that can't be done with a search-and-replace is too much while others wouldn't.
unless the existence of the deprecated thing is a large maintenance burden rather than just an annoyance.
Unfortunately that's hard to measure. For instance, the array.fromstring() deprecation that triggered this is probably fine to just leave, but if someone submits a PR to tweak the docs, the burden of that code suddenly went up. There's also the cost to users who import array, do a `dir(array)`, see fromstring(), and then start coding with it to find out later it's deprecated when they run their code (we all know people _should_ read docs first, but I'm sure we are all guilty of having not done it as well 😄). Once again, potentially small, but it also adds up across all Python developers (which is probably is past 10,000,000 people). The fact that all code is a shared resource/burden and everything has a cognitive cost to it even if it's just to choose to ignore a PR that touches deprecated code is why I'm asking about this. I think I will start a separate thread on this that's not tied to Python 2.7.
On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon
On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon brett@python.org wrote:
Python 3.9 is going to be the first release which will exist without any Python 2.7 overlap. Does this mean we are ready to start removing
Gregory P. Smith wrote: things
that have been deprecated since at least Python 3.7? PEP 4 says we are in the clear for modules, but I figured I would double-check as questions of cleaning up individual functions that have been deprecated for a very long time are now starting to come up (e.g. https://bugs.python.org/issue38916). If it has been through a usual deprecation cycle (in the past that was two releases... with 3.9's now accelerated schedule does it count as a full release for that purpose? if not, three releases is always good) it seems fair to consider removal. The only thing that would make me say "hold off" on a specific removal is if removing it will cause pain for people still dealing with a mixed 2.7 and 3.x codebase. ie: If it is an old API from the 2.x era and there is no easy way to accomplish the equivalent of that deprecation in 2.7 and 3.9+ without contortions I'd hold it just a little longer, until 3.10 or 3.11,
But what's an acceptable contortion? Some might say something that can't be done with a search-and-replace is too much while others wouldn't.
Anything a lib2to3 fixer could be written for. it probably isn't worth trying to define this without a list of practical examples. has anyone collected a list of things we deprecated but have yet to remove? I anticipate we may wind up in "oh yeah, just remove it all already" territory and this discussion will be moot. :)
unless the existence of the deprecated thing is a large maintenance burden
rather than just an annoyance.
Unfortunately that's hard to measure. For instance, the array.fromstring() deprecation that triggered this is probably fine to just leave, but if someone submits a PR to tweak the docs, the burden of that code suddenly went up. There's also the cost to users who import array, do a `dir(array)`, see fromstring(), and then start coding with it to find out later it's deprecated when they run their code (we all know people _should_ read docs first, but I'm sure we are all guilty of having not done it as well 😄). Once again, potentially small, but it also adds up across all Python developers (which is probably is past 10,000,000 people).
The fact that all code is a shared resource/burden and everything has a cognitive cost to it even if it's just to choose to ignore a PR that touches deprecated code is why I'm asking about this. I think I will start a separate thread on this that's not tied to Python 2.7.
By "large maintenance burden" I was specifically thinking of "the code existing in the CPython codebase is preventing other nice refactorings and redesigns from being done". Anytime a long deprecated thing gets in the way of such work, we should feel free to go ahead and remove it. I guess I'm advocating for not going on a deprecation rampage and removing all things we said would be gone by date $X unless there is a need. Changing our policy to always do them by date $X would also be reasonable. We could even come up with some post-release automation to auto-file bugs reminding us remove deprecated things after deprecation-release-1 is out. (we could require those get filed at deprecation time, but humans are good at humaning and may forget to do that, plus we don't have N+3 release tags for future release blockers to be filed in our bug tracker) -gps
_______________________________________________ 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/KDDIHOJI... Code of Conduct: http://python.org/psf/codeofconduct/
Gregory P. Smith wrote:
Gregory P. Smith wrote: On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon brett@python.org wrote: Python 3.9 is going to be the first release which will exist without any Python 2.7 overlap. Does this mean we are ready to start removing things that have been deprecated since at least Python 3.7? PEP 4 says we are in the clear for modules, but I figured I would double-check as questions of cleaning up individual functions that have been deprecated for a very long time are now starting to come up (e.g. https://bugs.python.org/issue38916). If it has been through a usual deprecation cycle (in the past that was two releases... with 3.9's now accelerated schedule does it count as a full release for that purpose? if not, three releases is always good) it seems fair to consider removal. The only thing that would make me say "hold off" on a specific removal is if removing it will cause pain for people still dealing with a mixed 2.7 and 3.x codebase. ie: If it is an old API from the 2.x era and there is no easy way to accomplish the equivalent of that deprecation in 2.7 and 3.9+ without contortions I'd hold it just a little longer, until 3.10 or 3.11, But what's an acceptable contortion? Some might say something that can't be done with a search-and-replace is too much while others wouldn't. Anything a lib2to3 fixer could be written for. it probably isn't worth
On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon brett@python.org wrote: trying to define this without a list of practical examples. has anyone collected a list of things we deprecated but have yet to remove? I anticipate we may wind up in "oh yeah, just remove it all already" territory and this discussion will be moot. :)
unless the existence of the deprecated thing is a large maintenance burden rather than just an annoyance. Unfortunately that's hard to measure. For instance, the array.fromstring() deprecation that triggered this is probably fine to just leave, but if someone submits a PR to tweak the docs, the burden of that code suddenly went up. There's also the cost to users who import array, do a dir(array), see fromstring(), and then start coding with it to find out later it's deprecated when they run their code (we all know people _should_ read docs first, but I'm sure we are all guilty of having not done it as well 😄). Once again, potentially small, but it also adds up across all Python developers (which is probably is past 10,000,000 people). The fact that all code is a shared resource/burden and everything has a cognitive cost to it even if it's just to choose to ignore a PR that touches deprecated code is why I'm asking about this. I think I will start a separate thread on this that's not tied to Python 2.7. By "large maintenance burden" I was specifically thinking of "the code existing in the CPython codebase is preventing other nice refactorings and redesigns from being done". Anytime a long deprecated thing gets in the way of such work, we should feel free to go ahead and remove it. I guess I'm advocating for not going on a deprecation rampage and removing all things we said would be gone by date $X unless there is a need. Changing our policy to always do them by date $X would also be reasonable.
I started a separate thread proposing that exact idea.
We could even come up with some post-release automation to auto-file bugs reminding us remove deprecated things after deprecation-release-1 is out. (we could require those get filed at deprecation time, but humans are good at humaning and may forget to do that, plus we don't have N+3 release tags for future release blockers to be filed in our bug tracker)
In my other thread I'm proposing a function to handle this which would change a DeprecationWarning to an actual exception once the removal version was reached so tests would start failing if it was left in.
participants (2)
-
Brett Cannon -
Gregory P. Smith