On 16. 11. 21 1:11, Brett Cannon wrote:
>
>
> On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner <vstinner@python.org
> <mailto:vstinner@python.org>> wrote:
>
>     On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith <eric@trueblade.com
>     <mailto:eric@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.