[Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

Eric Snow ericsnowcurrently at gmail.com
Thu Apr 26 12:42:52 EDT 2018


On Thu, Apr 26, 2018 at 12:52 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> [snip]
> here we would be *creating* one (two different assignment
> operators with overlapping use cases) that we won't be
> able to get rid of without a Python 4000 (that Guido has
> promised won't happen).

The edict about "Python 4000" is more about not repeating what
happened with Python 3 than strictly prohibiting breaking backward
compatibility. [1]  The way I understand it, the problem with Py3k was
that so many things changed in a backward-incompatible way.  Folks
could have coped with the unicode change as the big one for Python 2.7
(or 2.8 or 3.0 or whatever it ended up being).  However, so many other
things changed all at once that the burden to move to Python 3 became
daunting.  This included a number of back-compat-breaking syntax
changes.

Unless I've missed something, there's no prohibition against
deprecating things (and then later removing them) or other breaks in
backward compatibility.  We certainly avoid it, with good reason.
However, when we do break compatibility, the thing we want to avoid is
introducing too many such changes all at once (and to keep in mind
that such changes can add up to the same detriment when viewed in
aggregate across multiple releases).

That said, syntax is definitely a trickier target when it comes to
breaking backward compatibility.  So we have to be especially careful
about adding it in the first place.  I suppose that's a big part of
the reason for the strong reaction to the "binding expressions"
proposal.

-eric


[1] I'm hopeful we can consolidate a retrospective on Python 3 in a
PEP:  https://mail.python.org/pipermail/python-dev/2018-April/153131.html


More information about the Python-Dev mailing list