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. 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/
