On 16. 11. 21 1:11, Brett Cannon wrote:
On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner <vstin...@python.org
<mailto:vstin...@python.org>> wrote:
On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith <e...@trueblade.com
<mailto:e...@trueblade.com>> wrote:
> On second thought, I guess the existing policy already does this.
Maybe
> we should make it more than 2 versions for deprecations? I've written
> libraries where I support 4 or 5 released versions. Although maybe I
> should just trim that back.
If I understood correctly, the problem is more for how long is the new
way available?
I think Eric was suggesting more along the lines of PEP 387 saying that
deprecations should last as long as there is a supported version of
Python that *lacks* the deprecation. So for something that's deprecated
in 3.10, we wouldn't remove it until 3.10 is the oldest Python version
we support. That would be October 2025 when Python 3.9 reaches EOL and
Python 3.13 comes out as at that point you could safely rely on the
non-deprecated solution across all supported Python versions (or if you
want a full year of overlap, October 2026 and Python 3.14).
I think the key point with that approach is if you wanted to maximize
your support across supported versions, this would mean there wouldn't
be transition code except when the SC approves of a shorter deprecation.
So a project would simply rely on the deprecated approach until they
started work towards Python 3.13, at which point they drop support for
the deprecated approach and cleanly switch over to the new approach as
all versions of Python at that point will support the new approach as well.
That sounds like a reasonable minimum for minor cleanups -- breakage
that doesn't block improvements.
The current 'two years' minimum (and SC exceptions) is, IMO, appropriate
for changes that do block improvements -- e.g. if removing old Unicode
APIs allows reorganizing the internals to get a x% speedup, it should be
removed after the 2-years of warnings (*if* the speedup is also made in
that version -- otherwise the removal can be postponed).
Even better if there's some alternate API for the affected use cases
which works on all supported Python versions.
And then there are truly trivial removals like the "failUnless" or
"SafeConfigParser" aliases. I don't see a good reason to remove those --
they could stay deprecated forever. The only danger that API posed to
users is that it might be removed in the future (and that will break
their code), or that they'll get a warning or a linter nag.
_______________________________________________
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/THXWZ53X53I6GGLIDHO5T3Q4ZKALVGCP/
Code of Conduct: http://python.org/psf/codeofconduct/
