[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?
On 11/27/2019 10:38 AM, Brett Cannon wrote: What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal? I would advocate for a plan in which removals happen every so many releases -- in other words, if a removal release is being prepped and a feature has been deprecated for at least two cycles, toss it. With a yearly cadence I would suggest every 5 years. I.E. deprecated removed -- --- 3.6 3.10 3.7 3.10 3.8 3.10 3.9 3.15 3.10 3.15 This way folks know that upgrading from 3.8 to 3.9 should be painless, but going to 3.10 will require more careful search for deprecations. It also serves as a reminder for us to double-check for needed removals on */5 releases. -- ~Ethan~ ___ 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/4NYXNSXWETVXVSPXIXAXDVLYUGVBIJFR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?
> What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal? IMHO that really helps to reduce amount of discussions for choosing when to remove. Like should we remove it in 3.9 or we should wait to 3.10 etc. Also the consumers of that depracted parts will know the exact version they can't support if they'll continue using it. So big +1 from me On Wed, Nov 27, 2019, 9:43 PM Brett Cannon wrote: > What do people think of the idea of requiring all deprecations specifying > a version that the feature will be removed in (which under our annual > release cadence would be at least the third release from the start of the > deprecation, hence the deprecation being public for 2 years)? And that we > also follow through with that removal? > > Now I'm not suggesting it **must** be in three feature releases. A > deprecation could be set to Python 4 if people truly feel keeping the code > is as easy it gets in terms of maintenance and there's enough usage to > warrant such a potential indefinite deprecation/maintenance while keeping > the code and docs alive (basically "there are better ways to do this, but > this works fine, too, if you were already using it"). But what I am trying > to avoid is the semi-regular discussion we seem to have of what is or is > not reasonable to deprecate and leave versus deprecate and eventually > remove because we didn't specify what the eventual plan was for a > deprecation. Also feel like it would help users to know specifically what > the plan is with a deprecation rather than wondering if something will get > removed in the next feature release or not because we left off a specific > removal version. > > If people are amenable to this idea I will update PEP 387 (which I plan to > start a discussion about post-SC election) and I would also plan to add a > warnings._deprecate() which I roughly outlined once at > https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/18 > . > ___ > 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/BRA7G4UIGGW2X7YY55KQZBOGJEYNUV6O/ > 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/W24J7QWYLEBS7WB67IGTQV6QLD32TVRY/ 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 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] Should we require all deprecations to have a removal version that we follow through on?
What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal? Now I'm not suggesting it **must** be in three feature releases. A deprecation could be set to Python 4 if people truly feel keeping the code is as easy it gets in terms of maintenance and there's enough usage to warrant such a potential indefinite deprecation/maintenance while keeping the code and docs alive (basically "there are better ways to do this, but this works fine, too, if you were already using it"). But what I am trying to avoid is the semi-regular discussion we seem to have of what is or is not reasonable to deprecate and leave versus deprecate and eventually remove because we didn't specify what the eventual plan was for a deprecation. Also feel like it would help users to know specifically what the plan is with a deprecation rather than wondering if something will get removed in the next feature release or not because we left off a specific removal version. If people are amenable to this idea I will update PEP 387 (which I plan to start a discussion about post-SC election) and I would also plan to add a warnings._deprecate() which I roughly outlined once at https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/18. ___ 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/BRA7G4UIGGW2X7YY55KQZBOGJEYNUV6O/ 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/
