Gregory P. Smith wrote:
> On Tue, Nov 26, 2019 at 12:00 PM Brett Cannon brett@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-leave@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/