If there aren't backwards incompatible changes it will be called 3.10 not 4.0. Backwards Incompatibility is what changing the first number means.
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.
I dislike when people make promises about something set to happen a decade from then. Elected presidents can't keep their promises straight within half of that time and almost nobody remembers them. Promises which are aired on peak time TV to hundreds of millions of households. Who's gonna remember a blog post?
I'm not sure where you are getting that idea from? PEP 387[0] does indeed recommend programmatic warnings through the `warnings` module and eventual removal of deprecated features.
[0]: http://legacy.python.org/dev/peps/pep-0387/#making-incompati...
From the article we are discussing (emphasis added):
---quote--
the widespread development of "single source" Python 2/3 libraries and frameworks strongly encourages the use of "documented deprecation" in Python 3, even when features are replaced with newer, preferred, alternatives. In these cases, a deprecation notice is placed in the documentation, suggesting the approach that is preferred for new code, but no programmatic deprecation warning is added. This allows existing code, including code supporting both Python 2 and Python 3, to be left unchanged (at the expense of new users potentially having slightly more to learn when tasked with maintaining existing code bases).
---end of quote---
[0] https://twitter.com/gvanrossum/status/501172370690699265
He may know what he's talking about, but being a core python developer certainly doesn't necessitate that in my books.
They are humans, they have made mistakes. But you can't seriously argue that the majority of their decisions have been mistakes.
PHP is also widely used, but I wouldn't say the developers of PHP have made good decisions.
beautiful??? Atrocious more like.
Python is terribly put together (I'd say designed but it's clear no such process has taken place). It's a language that, like PHP and to some extent Perl before it, rewards idiotic behavior, makes it extremely easy to end up with horrible unmaintainable code and requires strict discipline and a lot of experience in order for it to "work" in anything that's not exploratory/throw-away in nature.
Of course the (mostly?) clueless masses love it, because they feel empowered. But really ask yourself, what has Python brought to the table in terms of paradigm shifts? It's no Lisp, Haskell or Ocaml.
Hell, even Java looks to be better, especially for beginner/mediocre programmers.
Bleh.
> 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.