[python-committers] Deprecation Policy PEP

[Ezio Melotti]

On Tue, Feb 2, 2016 at 4:54 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Tue, 02 Feb 2016 15:33:58 +0200, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum <guido at python.org> wrote:
>> > Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, etc.
>> >
>>
>> I think we should continue with 3.10, 3.11, etc.
>> Changing the major version should be done for incompatible changes,
>> and just doing it after 3.9 will probably just create confusion for
>> both users that will wonder if it's incompatible with Python 3 and for
>> things like the executable name.
>> Hopefully we won't need to jump to Python 4 for a long time.
>>
>> > I also want the 3->4 transition to feel like a non-event for most
>> > users. How we'll do that I don't know yet, but I want it to be a lot
>> > smoother than 2->3.
>
> I think Guido's point is that we shouldn't *make* incompatible changes,
> and that the 4.0 transition should be smooth so that people learn we are
> committed to that.  This is potentially analogous to the linux
> transition from 2.x to 3.x, despite the fact that it goes against the
> rules of semantic versioning.
>
> That said, I don't view removing deprecated things as a incompatible
> change, since code that has dealt with the deprecations will run on both
> the version before (usually versions plural) and the version after the
> removal.  Whether we should do a mass removal in 4.0 (or the first post
> 2.7 release) is a question, and so far the sense I get of the community
> is that there is not even close to a consensus on that.  But it would
> give a semantic versioning meaning to the change from 3.x to 4.x,
> without actually being all that disruptive.  On the other hand, a mass
> removal would be more disruption than removals spaced over several
> releases, so FUD might well arise as an issue, as you say.
>

There are two main types of changes that can make a new release
incompatible with the previous:
* removing/renaming (deprecated) APIs;
* semantic changes (e.g. int/int division, print function, lazy
builtins, nested scopes, absolute imports, unicode strings by default,
and adding new keywords);

For the former, we do it regularly in minor releases.  For the latter
the situation is more complicated.  We did most of those in 3.0, but
we changed semantics with nested scopes in 2.2 [0] and introduced new
keywords like "yield" and "with" in 2.3 [1] and 2.6 [2] (using
__future__ imports) first.
I believe that all these things can be done in a minor release, and
could have been done for Python 3.0 too, but it would have been really
difficult considering the magnitude of some of the changes.

Some amount of breakage happens with any new release, but we can
choose two different approaches:
1) spread the breakage evenly on several minor releases;
2) holding off until the next major release and do it at once;

If we choose the former, we might never need to bump the major release
to 4.0.  If we choose the latter (like we did for Python 3) we will
have an incompatible Python 4 (even though the incompatibilities might
be minor).
There's also a third option of bumping to 4.0 once some major (but
backward compatible) change is done, such as removing the GIL or
adding a JIT (or both).
I'm not sure making a mass-removal of deprecated APIs for 4.0 makes
too much sense, especially if we want to minimize breakage.

Also note that by choosing the first option we might increase the
chances that a program written for 3.6 won't run on e.g. 3.9, thus
forcing developers to keep up with the changes that each minor release
introduces.  Providing 3to3 fixers might make the transition easier.

What we decide will likely affect the deprecation policy we want to follow.

Best Regards,
Ezio Melotti

> Regardless though, the name is an issue :)
>
> So, I guess I see the arguments between going 3.9->4.0 vs 3.9->3.10
> as fairly balanced and don't have a strong preference.
>
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers