On 16. 11. 21 20:13, Brett Cannon wrote:
On Tue, Nov 16, 2021 at 4:46 AM Petr Viktorin <encu...@gmail.com
<mailto: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>
> <mailto: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>
> <mailto: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.
Yes, this thread is the first step :)
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.
I'm not looking for a contract, rather a best practice.
I think we should see Python's benign warts as nice gestures to the
users: signs that we're letting them focus on issues that matter to
them, rather than forcing them to join a quest for perfection.
If a wart turns out to be a tumor, we should be able to remove it after
the 2 years of warnings (or less with an exception). That's fine as a
contract. But I don't like "spring cleaning" -- removing everything the
contract allows us to remove.
Ensuring more perfect code should be a job for linters, not the
interpreter/stdlib.
_______________________________________________
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/NNKXTOSYXT2YH2FWZRFRMEFHYPN4BF66/
Code of Conduct: http://python.org/psf/codeofconduct/
