This sounds amazingly convenient! Language creators, please take note.
Maybe you meant "imagine if Python 3.6 automatically updated itself to Python 3.12"... Which would be amazing! Except that Python 3.12 is also not backwards compatible with Python 3.6. There's no saving Python.
All possible places for existing code to break, either via compiler errors, or changes in the expected runtime semantics.
> To ensure backwards compatibility with existing code, the new semantics will only apply in packages contained in modules that declare go 1.22 or later in their go.mod files.
CMake and Rust and Android and lots of other systems have mechanisms like this that allow you to introduce opt-in breaking changes, but unsurprisingly Python doesn't. They just decided it was ok to start breaking backwards compatibility.
Enough of them happened already, that a clarification post was needed,
Not at all. See https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... for reasons.
Please tell me what flag I can pass to Python 3.12 so `distutils` still exists.
I'm not familiar with Python, so I don't understand what is the problem with Python. But I think the problem of Go is unrelated to Python.
Not in fact. Go core team has admitted that Go toolchain 1.22.n versions break backward compatibility: https://github.com/golang/go/issues/66092
There is another breakage case: https://github.com/golang/go/issues/66070 and the team leader doesn't plan to fix it.
This doesn't make sense. The toolchain will be updated only IF you say your project only runs in Go >= XX. This is what `go` directive in `go.mod` says: my projects doesn't work in versions of Go older than this. This is why it happened to me, I declared I need `go 1.23` because of range-over-func, and the toolchain respected my wishes.
This is not an "enforcing you to use the latest Go version, even if you don't wish for it".