Why Python 4.0 won’t be like Python 3.0

That is what it means in SemVer, but SemVer is not a law. The author is the Director of the Python Software Foundation, so he's probably the second most qualified person in the world to comment on what the standards will be for 4.0 (the BDFL being the first).

He's essentially saying Python 3.x will be the last "major version" of Python as SemVer would describe it, but future bumps to the version number will be driven by decimalization rather than SemVer.

OTOH, while the current 2/3 split and maintenance of single source libraries may encourage "documented deprecation" as described in the article, that approach -- with no programmatic deprecation warnings and, consequently, never actually pruning the code of deprecated features, can't be a permanent state of affairs, if Python and its standard library are going to be maintainable in practice -- suggesting that it would be is essentially committing to unbounded accumulation of technical debt in the Python code base.

If PSF Python goes this way over the long term, I expect eventually a more nimble, decrufted fork will replace it for new development, with PSF Python relegated to legacy use.

> Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented. [Emphasis added]

I believe the intent of the sentence I've italicized is that while backwards incompatibility requires incrementing the major version, the converse is not necessary: a major version bump does not require backwards incompatibility.

Not that he has no reason for whining, he is just a bit overdramatic regarding some Python 3 issues - but since English is not my first language this impression may be the language barrier kicking in.

Ocaml, F#, Common Lisp, Scala/Clojure (if JVM) are languages that blow Python out of the water for anything that's not scripting/throw-away code.

What they are saying is that they won't introduce changes that break the way already existing code works, like they did by changing the underlying behavior of existing types. I think this is a reasonable compromise that allows for software developers to get access to new features, while at the same time refactoring their code once migrated to a new runtime.

There will of course be backwards incompatible changes introduced through a normal deprecation cycle. No one is suggesting Python remain static forever.

That may be what you'd prefer a major version number change to indicate, but the Director of the Python Software Foundation might have more insight than you into what the next major version number for Python will actually mean.

At any rate, the point of the article was that Python 2 to Python 3 levels of disruption are not going to happen again and that people waiting for that (the "Python 4000" people) are going to be disappointed, so they should stop proposing disruptive and non-backwards compatible enhancements that aren't compelling.

Where he says "no major backwards compatibility breaks" is important.

edit: more succinctly, "don't worry, we won't pull a 2 to 3 level move again any time soon, if ever"

Because the vast majority of the world's languages cannot be handled solely using ASCII?

That's exactly what Python did. It's also a problem, because it's a change in a core feature of the language.

I think a better idea would be to have a string type that is encoding-agnostic (and internally might depend on compilation switches) but conceptually isomorphic to numbers in the range [0, 2^32) and a binary-data type which may have an encoding "annotation". And then the string type should be mostly not used, especially in the standard library. That way the cost of dealing with transformations among various encodings will be borne by those who care about those encodings, which isn't something that can be said of python3.

If one were developing a language from scratch, it would also be convenient that loads of legacy code doesn't assume the triviality of transformations between strings and binary data, or between different encodings of binary data. Obviously python3 couldn't rely on this convenience, but I wonder if we weren't making more trouble for ourselves by setting an expectation that str would be used all the time, and bytes only when absolutely necessary. I suspect the opposite custom would have been less troublesome.