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/
