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/
