> 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.
To be fair, there's a long way to 2023 when 3.10/4.0 is expected to be released. The guy could be gone from the Python community for a number of reasons. Public opinion on numbering could have changed for a number of reasons. Backwards incompatible changes could be required for a number of reasons. Heck, it's even enough time for SemVer to be voted into law.
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?
> 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.
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.
> I'm not sure where you are getting that idea from?
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).
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.