On Thu, Apr 26, 2018 at 12:52 AM, Greg Ewing <greg.ew...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
