[Python-Dev] Re: Are we ready to start cleaning up deprecated stuff?
Gregory P. Smith wrote: > On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon br...@python.org wrote: > > Gregory P. Smith wrote: > > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon > > br...@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 > 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/44AYRD5HGQLPZTXHSW4GGM4X32MBR2J6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are we ready to start cleaning up deprecated stuff?
On Wed, Nov 27, 2019 at 10:15 AM Brett Cannon wrote: > Gregory P. Smith wrote: > > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon br...@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 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-le...@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/KDDIHOJIHSAKNKJIYCOJM5ZELVFAQGFH/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/DRH3PXRQITWDTX73RJGSNNNMGFKJAOKC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are we ready to start cleaning up deprecated stuff?
Gregory P. Smith wrote: > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon br...@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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/KDDIHOJIHSAKNKJIYCOJM5ZELVFAQGFH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are we ready to start cleaning up deprecated stuff?
On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon 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]( > https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5), > 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/IVWSS7C26MXUTPLOT3E6ASDNZQQ2YBD2/ Code of Conduct: http://python.org/psf/codeofconduct/
