4 ms·

This sounds amazingly convenient! Language creators, please take note.

• sgt 2y ago
  Imagine if Python 2 automatically upgraded itself to Python 3.
  • iand 2y ago
    Imagine if Python had as strong a compatibility promise as Go
  • IshKebab 2y ago
    Python 3 is not backwards compatible with Python 2 so why would it do that? 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.
    • pjmlp 2y ago
      Same is also starting to apply to Go runtime, standard library and even some minor fixes like the for loop variables lifetime. All possible places for existing code to break, either via compiler errors, or changes in the expected runtime semantics.
      • IshKebab 2y ago
        Even in that case they did the behaviour change properly: > 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.
        • pjmlp 2y ago
          That doesn't apply to runtime and standard library changes. Enough of them happened already, that a clarification post was needed, https://go.dev/blog/compat https://go.dev/blog/compat
          • IshKebab 2y ago
            That's still among the strongest backwards compatibility guarantees in any major language. Maybe Java would be close? It's certainly better than C++ which is famed for backwards compatibility, and light years ahead of Python.
            • pjmlp 2y ago
              Yet it isn't without zero issues, as claimed.
            • tapirl 2y ago
              > That's still among the strongest backwards compatibility guarantees in any major language. Not at all. See https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... for reasons.
              • IshKebab 2y ago
                What reasons? You need to pass one flag to the compiler to specify the language version? That's still very very good. Please tell me what flag I can pass to Python 3.12 so `distutils` still exists.
                • tapirl 2y ago
                  Reasons are in the article. 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.
        • tapirl 2y ago
  • trw9991019 2y ago
    I don't like Python much, but they will definitely not pull off something like this (again), because they've actually learned from that mistake and broadly agree that it was one.
  • danslo 2y ago
    After explicitly setting the python version to 3 in package.json? Yes please!
  • kokada 2y ago
    Author here. 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".
  • chuckadams 2y ago
    It’s more like if virtualenv looked in requirements.txt for the Python version and used that version locally. Other languages like Haskell and Scala have been doing that sort of thing for ages.