5 ms·

I agree completely, plus there are all the conflicting ways of installing and managing Python programs, dependencies, and environments, and the poor quality of

I agree completely, plus there are all the conflicting ways of installing and managing Python programs, dependencies, and environments, and the poor quality of so much Python code, some of it widely used. I find myself having to switch the `python` symlink in my path between python2 and python3 regularly, I look forward to the day when I can purge my systems of all traces of Python.

wildrhythms 4y ago
The number of times I find a script that blindly assumes 'python' points to its required version is too damn high. It makes me question the general competency of the people shipping Python code.
- leephillips 4y ago
  It’s inexcusable in recent scripts, but some of these date from the time when there was only python2. No, the root of the problem, as pointed out by many others here, is the policy decision to create two incompatible interpreters both called “python”.
  - jeroenhd 4y ago
    I think it's actually more excusable in recent scripts as Python 2.7 has been deprecated and unsupported for ages now. You won't know what version of Python 3 you're getting, but at this point it's safe to assume you're getting a version of Python 3 when you call python. Only old scripts written when Python 2 and 3 were maintained separately should've ever had this problem, but we're past that point now.
    - bloblaw 4y ago
      Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that. How about one with dataclasses support? Again, you get to install a new interpreter everywhere. Python packaging continues to be a sore spot for the language.
      - jeroenhd 4y ago
        You're getting the Python version you've specified as a requirement in your requirements.txt, unless your users ignore or bypass that. What language features you support depend on the minimum version you pick, and if you choose to go bleeding edge/not pick a version/pick a version and use newer features anyway, you're responsible for getting support to work.
        bloblaw 4y ago
        But what if you just write a Python3 script and want to run it? Not a full blown application, but just a script. I mean the Python ecosystem is such that now I have to "package" up this script to potentially tell the user with Python 3.6 that they need to download a new interpreter version (eg 3.9) to run my application (and any dependencies). This puts all the pain of running a script on every user that wants to run it. I've said it before, but Python requires users to replicate the developers environment...and somehow this is fine?!? Statically compiled languages (eg Go, Nim, Rust, C/C++, Obj-Pascal, D, etc) ship binaries...that just run. Obligatory xkcd: https://xkcd.com/1987/ https://xkcd.com/1987/
        jeroenhd 4y ago
        If you just want to write a script, you likely know the version available on your system. When in doubt, add the #!/bin/env python3.10 shebang to the top of your script to ensure the version it's running on is the same as the version you're writing the script for. If I build an application on Linux I need to specify a glibc version or a PHP version or a Java version in some way as well. I don't see what this has to do with Python. Good luck running a jar built with JDK19 on JRE8, or an executable linked against glibc2.36 on Ubuntu 18, or a Python file written for Python 3.10 on a system that comes with Python 3.6. Statically compiled languages come with their own problems (note that C++, Go and Rust also have system requirements, I've had to deal with a Go executable that would not work in a musl environment and a Rust executable that I needed to build on Ubuntu because the compiled version from my Manjaro laptop linked a against a libc version that was too recent). If you need dependencies, specify and install them. If your only dependency is the interpreter, document it, specify it in the shebang, or deal with it. Python 3 is completely backwards compatible in my experience, it's only the programs that stuck with Python 2 for a decade that have trouble running on modern machines in my experience.

wildrhythms 4y ago

The number of times I find a script that blindly assumes 'python' points to its required version is too damn high. It makes me question the general competency of the people shipping Python code.

leephillips 4y ago
It’s inexcusable in recent scripts, but some of these date from the time when there was only python2. No, the root of the problem, as pointed out by many others here, is the policy decision to create two incompatible interpreters both called “python”.
- jeroenhd 4y ago
  I think it's actually more excusable in recent scripts as Python 2.7 has been deprecated and unsupported for ages now. You won't know what version of Python 3 you're getting, but at this point it's safe to assume you're getting a version of Python 3 when you call python. Only old scripts written when Python 2 and 3 were maintained separately should've ever had this problem, but we're past that point now.
  - bloblaw 4y ago
    Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that. How about one with dataclasses support? Again, you get to install a new interpreter everywhere. Python packaging continues to be a sore spot for the language.
    - jeroenhd 4y ago
      You're getting the Python version you've specified as a requirement in your requirements.txt, unless your users ignore or bypass that. What language features you support depend on the minimum version you pick, and if you choose to go bleeding edge/not pick a version/pick a version and use newer features anyway, you're responsible for getting support to work.
      - bloblaw 4y ago
        But what if you just write a Python3 script and want to run it? Not a full blown application, but just a script. I mean the Python ecosystem is such that now I have to "package" up this script to potentially tell the user with Python 3.6 that they need to download a new interpreter version (eg 3.9) to run my application (and any dependencies). This puts all the pain of running a script on every user that wants to run it. I've said it before, but Python requires users to replicate the developers environment...and somehow this is fine?!? Statically compiled languages (eg Go, Nim, Rust, C/C++, Obj-Pascal, D, etc) ship binaries...that just run. Obligatory xkcd: https://xkcd.com/1987/ https://xkcd.com/1987/
        jeroenhd 4y ago
        If you just want to write a script, you likely know the version available on your system. When in doubt, add the #!/bin/env python3.10 shebang to the top of your script to ensure the version it's running on is the same as the version you're writing the script for. If I build an application on Linux I need to specify a glibc version or a PHP version or a Java version in some way as well. I don't see what this has to do with Python. Good luck running a jar built with JDK19 on JRE8, or an executable linked against glibc2.36 on Ubuntu 18, or a Python file written for Python 3.10 on a system that comes with Python 3.6. Statically compiled languages come with their own problems (note that C++, Go and Rust also have system requirements, I've had to deal with a Go executable that would not work in a musl environment and a Rust executable that I needed to build on Ubuntu because the compiled version from my Manjaro laptop linked a against a libc version that was too recent). If you need dependencies, specify and install them. If your only dependency is the interpreter, document it, specify it in the shebang, or deal with it. Python 3 is completely backwards compatible in my experience, it's only the programs that stuck with Python 2 for a decade that have trouble running on modern machines in my experience.