On Tue, Nov 16, 2021 at 4:46 AM Petr Viktorin <encu...@gmail.com> wrote:
> 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. > If enough people come forward supporting this idea then you could propose to the SC that PEP 387 get updated with this guidance. -Brett > > > > 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. > If deprecations ever become permanent, then there will have to be a cleaning of the stdlib first before we lock the team into this level of support contract.
_______________________________________________ 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/D47IPVKOFREETNKNDWDDJY5NWBGQAN66/ Code of Conduct: http://python.org/psf/codeofconduct/
