8 ms·

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

by pcl 3y ago

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

nerdponx 3y ago
Right, and Go has the luxury of being a compiler that generates reasonably portable binaries, while Python requires the presence of an interpreter on the system at run time.
- josephg 3y ago
  The same trick would work with python just as well. There’s nothing about Python’s status as an interpreter which would stop them from adding a python semantic version somewhere in each python program - either in a comment at the top of each source file or in an adjacent config file. The comment could specify the version of python’s semantics to use, which would allow people to opt in to new syntax (or opt out of changes which may break the code in the future). Eg # py 3.4
  - Cthulhu_ 3y ago
    Yeah, it would just mean that the interpreter - just like the Go compiler - would need to have the equivalent of "if version > 3.4 do this, else do that". Which is fine for a while, but I can imagine it adds a lot of complexity and edge cases to the interpreter / compiler. Which makes me think that a Go 2.0 or Python 4 will mainly be about removing branches and edge cases from the compiler more than making backwards-incompatible language changes.
    - josephg 3y ago
      This is the direction multiple languages are moving in. Go and Rust both have something like this. (In Rust they're called "editions"). I think its inevitable that compilers get larger over time. I hope most of the time they aren't too onerous to maintain - there aren't that many spec breaking changes between versions. But if need be, I could also imagine the compiler eventually deprecating old versions if it becomes too much of an issue. Arguably C & C++ compilers do the same thing via -std=c99 and similar flags at compile time. Anyway, nothing about this is special or different with python. I bet the transition to python 3 would have been much smoother if scripts could have opted in (or opted out) of the new syntax without breaking compatibility.
- lloeki 3y ago
  > Python requires the presence of an interpreter on the system at run time. A runtime interpreter does not prevent Perl to do similar things via `use 5.13` Python has `from future` with similar abilities, it would absolutely be possible to do the same as Perl and Go and fix what needs to be fixed without breaking old code. One could design a `import 3.22` and `from 3.22 import unbroken_for` and achieve the same thing.
IshKebab 3y ago
Python could very easily have a similar mechanism. Hell even CMake manages to do this right, and they got "if" wrong. The Python devs sometimes seem stubbornly attached to bugs. Another one: to reliably get Python 3 on Linux and Mac you have to run `python3`. But on Windows there's no `python3.exe`. Will they add one? Hell no. It might confuse people or something. Except... if you install Python from the Microsoft Store it does have `python3.exe`.
- wrboyce 3y ago
  I’ve not run “python3” in years on my Mac, and I’m almost certain I never type it into Linux machines either; either I’m losing my mind, or there are some ludicrous takes in this thread.
  - rat9988 3y ago
    You are surely losing your mind then. Python3 isn't something esoteric.
    - wrboyce 3y ago
      Entirely possible, but my point was I just type “python” and Python 3 happens. Do modern OS even come with Python 2 anymore? I’m not claiming any mystery about Python, just disputing how the modern version is invoked.
      - erik_seaberg 3y ago
        13.5.2 has /usr/bin/python3 (it’s 3.9.6) but not python2 or just python. Not sure when they changed, and YMMV with Homebrew.
      - lmm 3y ago
        > I just type “python” and Python 3 happens. That was the old way. Python now recommends against installing Python3 in a way that does that, and most modern *nix don't.
      - 3y ago

by pcl 3y ago

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

nerdponx 3y ago

Right, and Go has the luxury of being a compiler that generates reasonably portable binaries, while Python requires the presence of an interpreter on the system at run time.

josephg 3y ago
The same trick would work with python just as well. There’s nothing about Python’s status as an interpreter which would stop them from adding a python semantic version somewhere in each python program - either in a comment at the top of each source file or in an adjacent config file. The comment could specify the version of python’s semantics to use, which would allow people to opt in to new syntax (or opt out of changes which may break the code in the future). Eg # py 3.4
- Cthulhu_ 3y ago
  Yeah, it would just mean that the interpreter - just like the Go compiler - would need to have the equivalent of "if version > 3.4 do this, else do that". Which is fine for a while, but I can imagine it adds a lot of complexity and edge cases to the interpreter / compiler. Which makes me think that a Go 2.0 or Python 4 will mainly be about removing branches and edge cases from the compiler more than making backwards-incompatible language changes.
  - josephg 3y ago
    This is the direction multiple languages are moving in. Go and Rust both have something like this. (In Rust they're called "editions"). I think its inevitable that compilers get larger over time. I hope most of the time they aren't too onerous to maintain - there aren't that many spec breaking changes between versions. But if need be, I could also imagine the compiler eventually deprecating old versions if it becomes too much of an issue. Arguably C & C++ compilers do the same thing via -std=c99 and similar flags at compile time. Anyway, nothing about this is special or different with python. I bet the transition to python 3 would have been much smoother if scripts could have opted in (or opted out) of the new syntax without breaking compatibility.
lloeki 3y ago
> Python requires the presence of an interpreter on the system at run time. A runtime interpreter does not prevent Perl to do similar things via `use 5.13` Python has `from future` with similar abilities, it would absolutely be possible to do the same as Perl and Go and fix what needs to be fixed without breaking old code. One could design a `import 3.22` and `from 3.22 import unbroken_for` and achieve the same thing.

IshKebab 3y ago

Python could very easily have a similar mechanism. Hell even CMake manages to do this right, and they got "if" wrong. The Python devs sometimes seem stubbornly attached to bugs. Another one: to reliably get Python 3 on Linux and Mac you have to run `python3`. But on Windows there's no `python3.exe`. Will they add one? Hell no. It might confuse people or something. Except... if you install Python from the Microsoft Store it does have `python3.exe`.

wrboyce 3y ago
I’ve not run “python3” in years on my Mac, and I’m almost certain I never type it into Linux machines either; either I’m losing my mind, or there are some ludicrous takes in this thread.
- rat9988 3y ago
  You are surely losing your mind then. Python3 isn't something esoteric.
  - wrboyce 3y ago
    Entirely possible, but my point was I just type “python” and Python 3 happens. Do modern OS even come with Python 2 anymore? I’m not claiming any mystery about Python, just disputing how the modern version is invoked.
    - erik_seaberg 3y ago
      13.5.2 has /usr/bin/python3 (it’s 3.9.6) but not python2 or just python. Not sure when they changed, and YMMV with Homebrew.
    - lmm 3y ago
      > I just type “python” and Python 3 happens. That was the old way. Python now recommends against installing Python3 in a way that does that, and most modern *nix don't.
    - 3y ago