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)
(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.)
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.
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.
> 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:
Yes, indeed it would.