Gregory P. Smith wrote: > On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/KDDIHOJIHSAKNKJIYCOJM5ZELVFAQGFH/ Code of Conduct: http://python.org/psf/codeofconduct/