3 ms·

This would be a backward-incompatible change, no? In other languages, such a change would only be possible with a major version bump, though I imagine that bec

by sph 2y ago

This would be a backward-incompatible change, no? In other languages, such a change would only be possible with a major version bump, though I imagine that because of the Python 3 collective trauma, the language designers now are OK with breaking older code without calling it Python 4. Anything goes, as long as it's called Python 3. (Python lost me in the 2->3 migration and I haven't used it in a decade, so correct me if I'm wrong)

letmeinhere 2y ago
Python doesn't use semantic versioning. The number after the first period is a major (annual) release and can and does contain breaking changes (though so far never on the scale of the 2->3 upgrade). We may never see a 4.0 because of the scar tissue, but the language continues to evolve.
- sph 2y ago
  Linux: let's bump the major version just because Python: for the love of God [1] don't touch the version I wonder if the scar tissue will ever heal and we'll see a Python 4 in two decades. 1: https://www.youtube.com/watch?v=asUyK6JWt9U https://www.youtube.com/watch?v=asUyK6JWt9U
  - hnlmorg 2y ago
    Probably not before a Perl 6
  - sgarland 2y ago
    K8s: the major version will never change, so instead we’ll introduce breaking changes with minor versions.
- infamia 2y ago
  > We may never see a 4.0 because of the scar tissue, but the language continues to evolve. They should do the opposite really. If it hurts, do it more often and get better at it. A perfect time would be when Python gets some nice JIT performance improvements which everyone will probably like.
mananaysiempre 2y ago
I don’t think there have been significant backwards-incompatible changes in Python 3 the language. There have been some, e.g. async and await were first introduced as soft keywords and then switched to being actual ones. But that’s not all that different from the treatment of yield in Python 2. (Recent stdlib changes have been much more destructive, but I’m assuming that, like in the original thread, we’re drawing a distinction between those and changes to the actual language.) Full disclosure, I welcomed Python 3, because for me that was the first time (since 2.4 on Windows XP) that I could count on my programs not randomly shitting their pants upon encountering Cyrillic in files or filenames, which for a native speaker of Russian you can imagine is quite important. (The csv stdlib module in Python 2 did that, IIRC. Perhaps I was holding it wrong, but experience shows that absolutely everybody did.)
- echoangle 2y ago
  I think basically every new python version removes some standard libs and marks new ones as deprecated (at least 3.13 did), that’s potentially breaking.
  - zahlman 2y ago
    The bytecode format changes, too, as does the C ABI (although they're making improvements on the latter front - there's supposed to be a more stable subset now). But more recently, they committed to a proper scheduling procedure for standard library deprecations and removals.
  - mananaysiempre 2y ago
    Incompatible library changes do happen, but the 3.11–13 removals, or more specifically PEP 594[1] removals, were abnormally destructive. [1] https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/
- wren6991 2y ago
  One that bit me was the change to StopIteration propagating through chained generators, following PEP 479. Nothing huge, but I had to patch some previously working code to accommodate the new language release.
pdonis 2y ago
> This would be a backward-incompatible change Yes, indeed it would.
neuronexmachina 2y ago
Yes, from PEP 760's draft: https://peps.python.org/pep-0760/ https://peps.python.org/pep-0760/ > This change is not backwards compatible. Existing code that uses bare `except:` clauses will need to be modified. To ease the transition: > * A deprecation warning will be issued for bare `except` clauses in Python 3.14. > * The syntax will be fully disallowed in Python 3.17. > * A `from __future__ import strict_excepts` will be provided to invalidate bare except handlers in earlier versions of Python. > A tool will be provided to automatically update code to replace bare `except:` with except BaseException:

by sph 2y ago

letmeinhere 2y ago

Python doesn't use semantic versioning. The number after the first period is a major (annual) release and can and does contain breaking changes (though so far never on the scale of the 2->3 upgrade). We may never see a 4.0 because of the scar tissue, but the language continues to evolve.

sph 2y ago
Linux: let's bump the major version just because Python: for the love of God [1] don't touch the version I wonder if the scar tissue will ever heal and we'll see a Python 4 in two decades. 1: https://www.youtube.com/watch?v=asUyK6JWt9U https://www.youtube.com/watch?v=asUyK6JWt9U
- hnlmorg 2y ago
  Probably not before a Perl 6
- sgarland 2y ago
  K8s: the major version will never change, so instead we’ll introduce breaking changes with minor versions.
infamia 2y ago
> We may never see a 4.0 because of the scar tissue, but the language continues to evolve. They should do the opposite really. If it hurts, do it more often and get better at it. A perfect time would be when Python gets some nice JIT performance improvements which everyone will probably like.

mananaysiempre 2y ago

I don’t think there have been significant backwards-incompatible changes in Python 3 the language. There have been some, e.g. async and await were first introduced as soft keywords and then switched to being actual ones. But that’s not all that different from the treatment of yield in Python 2. (Recent stdlib changes have been much more destructive, but I’m assuming that, like in the original thread, we’re drawing a distinction between those and changes to the actual language.) Full disclosure, I welcomed Python 3, because for me that was the first time (since 2.4 on Windows XP) that I could count on my programs not randomly shitting their pants upon encountering Cyrillic in files or filenames, which for a native speaker of Russian you can imagine is quite important. (The csv stdlib module in Python 2 did that, IIRC. Perhaps I was holding it wrong, but experience shows that absolutely everybody did.)

echoangle 2y ago
I think basically every new python version removes some standard libs and marks new ones as deprecated (at least 3.13 did), that’s potentially breaking.
- zahlman 2y ago
  The bytecode format changes, too, as does the C ABI (although they're making improvements on the latter front - there's supposed to be a more stable subset now). But more recently, they committed to a proper scheduling procedure for standard library deprecations and removals.
- mananaysiempre 2y ago
  Incompatible library changes do happen, but the 3.11–13 removals, or more specifically PEP 594[1] removals, were abnormally destructive. [1] https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/
wren6991 2y ago
One that bit me was the change to StopIteration propagating through chained generators, following PEP 479. Nothing huge, but I had to patch some previously working code to accommodate the new language release.

pdonis 2y ago

> This would be a backward-incompatible change Yes, indeed it would.

neuronexmachina 2y ago

Yes, from PEP 760's draft: https://peps.python.org/pep-0760/ https://peps.python.org/pep-0760/ > This change is not backwards compatible. Existing code that uses bare `except:` clauses will need to be modified. To ease the transition: > * A deprecation warning will be issued for bare `except` clauses in Python 3.14. > * The syntax will be fully disallowed in Python 3.17. > * A `from __future__ import strict_excepts` will be provided to invalidate bare except handlers in earlier versions of Python. > A tool will be provided to automatically update code to replace bare `except:` with except BaseException: