On Wed, 1 Jun 2022 at 03:41, Christopher Barker <pythonchb@gmail.com> wrote:
In fact, I don’t think there’s been a breaking change since the Py3 transition.
I think PEP 563 was going to be the first — and that’s been delayed.
Depends on your definition of "breaking". For instance, this code is legal in Python 3.9, gives a DeprecationWarning in 3.10, and will eventually be illegal:
5in range(10) True
Technically, that's a breaking change. It's currently legal, and eventually won't. But (a) very little code will use this intentionally, and (b) it's trivially easy to fix it in a way that works on older versions (since the more normal way of writing it, with a space before the word "in", is compatible with every version of Python known to mankind, or thereabouts). Similarly, collections.Mapping has been deprecated since 3.3 (use collections.abc.Mapping instead), and that's no longer legal. It, too, gave a warning for a couple of versions. Generally, with every new Python version, it's a good idea to check the What's New for anything that's been removed, but for the most part, code won't break, or if it does, it'll be only in very minor ways. (One thing that Python really tries extremely hard to avoid is behavioural changes, where the same syntax is legal in multiple versions, but does different things. Those are extremely difficult to cope with in cross-version code.) Making something illegal that was previously valid is definitely possible, but it needs strong justification. Given that the "was this a list or a numpy array?" question can never be answered safely when you multiply by a positive integer, I'm dubious of the value of detecting an error when you multiply by a negative integer. It would be a backward compatibility break for fairly low value, in my opinion. ChrisA