4 ms·

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.

ludamad 12y ago
Right, this confused me too. He mentions 4.0 will be 'more likely than 3.10', but never explains why.
ayrx 12y ago
The author is a CPython core developer so I expect he has some idea what he is talking about. Nothing guarantees that CPython will stick to semantic versioning. There is precedent for that in the way the Linux kernel is doing version numbers now.
- shadowmint 12y ago
  ...because the cpython core developers have a history of making good decisions. He may know what he's talking about, but being a core python developer certainly doesn't necessitate that in my books.
  - ayrx 12y ago
    Of course they do. They made an elegant, beautiful and widely used language. They are humans, they have made mistakes. But you can't seriously argue that the majority of their decisions have been mistakes.
    - wtetzner 12y ago
      Widely used is the only thing in your list that's not subjective, and also the only one I agree with. PHP is also widely used, but I wouldn't say the developers of PHP have made good decisions.
    - latiera 12y ago
      elegant?? It's 2014 and Guido is talking about event loops. 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.
  - dragonwriter 12y ago
    Good decisions are really irrelevant -- being a core developer (and, more importantly, Director of the PSF) means that Coghlan has considerable insight onto what kind of changes are likely to to be accepted in Python versions with particular version numbers, independent of whether those decisions are good or not.
dragonwriter 12y ago
> 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.
- ayrx 12y ago
  > 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. [0]: http://legacy.python.org/dev/peps/pep-0387/#making-incompatible-changes http://legacy.python.org/dev/peps/pep-0387/#making-incompati...
  - dragonwriter 12y ago
    > 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). ---end of quote---
chubot 12y ago
They don't use semantic versioning. Python 2.0 was compatible with Python 1.5. (There was a licensing change, but that doesn't mean anything in semantic versioning)
ScottBurson 12y ago
From the Semantic Versioning 2.0 spec: > 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.

ludamad 12y ago

Right, this confused me too. He mentions 4.0 will be 'more likely than 3.10', but never explains why.

ayrx 12y ago

The author is a CPython core developer so I expect he has some idea what he is talking about. Nothing guarantees that CPython will stick to semantic versioning. There is precedent for that in the way the Linux kernel is doing version numbers now.

shadowmint 12y ago
...because the cpython core developers have a history of making good decisions. He may know what he's talking about, but being a core python developer certainly doesn't necessitate that in my books.
- ayrx 12y ago
  Of course they do. They made an elegant, beautiful and widely used language. They are humans, they have made mistakes. But you can't seriously argue that the majority of their decisions have been mistakes.
  - wtetzner 12y ago
    Widely used is the only thing in your list that's not subjective, and also the only one I agree with. PHP is also widely used, but I wouldn't say the developers of PHP have made good decisions.
  - latiera 12y ago
    elegant?? It's 2014 and Guido is talking about event loops. 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.
- dragonwriter 12y ago
  Good decisions are really irrelevant -- being a core developer (and, more importantly, Director of the PSF) means that Coghlan has considerable insight onto what kind of changes are likely to to be accepted in Python versions with particular version numbers, independent of whether those decisions are good or not.

dragonwriter 12y ago

> 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.

ayrx 12y ago
> 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. [0]: http://legacy.python.org/dev/peps/pep-0387/#making-incompatible-changes http://legacy.python.org/dev/peps/pep-0387/#making-incompati...
- dragonwriter 12y ago
  > 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). ---end of quote---

chubot 12y ago

They don't use semantic versioning. Python 2.0 was compatible with Python 1.5. (There was a licensing change, but that doesn't mean anything in semantic versioning)

ScottBurson 12y ago

From the Semantic Versioning 2.0 spec: > 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.