Hacker News new | ask | show | jobs
by sdeer 1683 days ago
Any reason why he can't use

  #!/usr/bin/env python
here?
6 comments

The main example I can think of is when you don't know what python links to. For example, an Arch system will links to some version of Python 3. I believe that Debian based systems link to some version of Python 2. You could just swap python with python3, but if your script supports Python 2 as well and you're trying to run it on a system without Python 3, it will fail.

Of course, if your script will run under both Python 2 and 3, I don't know why you would want to use these contrivances to simply give preference to Python 3.

>Ever had a script that's compatible with both, Python 2 and 3...

The article is literally about this scenario, which is why I'm also confused. Yes, `/usr/bin/env python` is a bad idea IF your script depends on a certain version, but that's exactly what the author doesn't need!

> I believe that Debian based systems link to some version of Python 2.

Since Debian 11 and Ubuntu 20.04 LTS it's a matter of installing the matching package:

python-is-python2 [1] for having /usr/bin/python link to Python 2.7, python-is-python3 [2] for having /usr/bin/python link to Python 3.x or none of them to avoid having /usr/bin/python at all. The latter one will still result in a working system, as all Python scripts shipped by Debian/Ubuntu nowadays explicitly specify /usr/bin/python2 or /usr/bin/python3.

[1]: https://packages.debian.org/bullseye/python-is-python2

[2]: https://packages.debian.org/bullseye/python-is-python3

Oh god. No, not having a `/usr/bin/python` will not result in a working system. Does Debian really think they're the only software distributor that their users use?
No, which is why the “python-is-python2” and “python-is-python3” packages exist.
Great! Except that apparently, you can have neither of those packages installed.
> I don't know why you would want to use these contrivances to simply give preference to Python 3.

Performance gains, preferring future-looking development, and better error messages.

If you're living in limbo where "python" still means "python2", which isn't installed, as opposed to "python3", then this wouldn't work.

Or theoretically also the other way around.

If you don't care which version of python it runs under, you do this:

    #!/usr/bin/env python
If you do, then `python2` or `python3` will be around, and you should specify them explicitly instead of `python`. I'm happy to be corrected on this one, but I always slap this at the top of my scripts:

    #!/usr/bin/env python3
I'm not aware of anywhere that wouldn't invoke a Python 3 interpreter if one is installed.

The original post just seems like one big faff.

My system doesn't have a `python`. On Ubuntu you need to install one of the `python-is-python2` or `python-is-python3` packages for the `python` command to be available.

  Command 'python' not found, did you mean:

    command 'python3' from deb python3
    command 'python' from deb python-is-python3
https://packages.ubuntu.com/focal/python-is-python3
All Debian based distros are this way, not just Ubuntu.
And a lot of non-Debian distros as well. Python 2 is officially retired after all.
PEP 394 (which is now superseeded) clearly states that "python" shall invoke python2 and not python3

https://www.python.org/dev/peps/pep-0394/

"The python command should always invoke Python 2 (to prevent hard-to-diagnose errors when Python 2 code is run on Python 3)."

So there was indeed a time where the mentioned scenario was possible.

Edit: love those people who got to downvote reality. At no point was python pointing to either 2 or 3 will-nilly, but there was always a PEP specifying best practice behaviour.

> "python" shall invoke python2 and not python3

The current version of PEP 394 says:

] If the python command is installed, it is expected to invoke either the same version of Python as the python3 command or as the python2 command.

] Distributors may choose to set the behavior of the python command as follows:

    python2,
    python3,
    not provide python command,
    allow python to be configurable by an end user or a system administrator.

The part you quoted is from the section "History of this PEP". Just before your quoted text is:

] This PEP originally provided a very simple mechanism ...

and just after it is:

] However, these recommendations implicitly assumed that Python 2 would always be available.

This historic advice is no longer recommended.

The change was made on July 5, 2019 - https://github.com/python/peps/commit/ae932bd6fd2c493d7d64ce... .

The PEP is not superseded, still active. You got this quote from the "history of this PEP" section. This is not what the PEP currently mandates and it hasn't for 2.5 years: https://github.com/python/peps/pull/989
That was not the point. There was a time where the PEP specified that "python" means "python2" and it was indeed possible to have no "python" but still a Python (3) installation.
This link may not exist. Notably, if you start with minimal bootstrap of ubuntu focal (20.04) and install "python3" package, you'll end up with "python3" and not "python"
Another point here is that python is still commonly a python 2.7 on a lot of deployed systems. It's going to be years before it's safe to assume that python is anything else...

(Ubuntu LTSs and macOs are an example ...)

No, that's not another point. It's a point that was made hours before you in a sibling comment AND it's a point that is completely irrelevant. Read the second sentence of TFA.
'python' might not be a valid command because 'python3' exists and 'python' does not.

When designing things for 'just work' scripts you have to take esoteric environments into account.

There is no guarantee that '#!/usr/bin/env python' will not error in an environment with only python3 installed.

There is also no guarantee that Python is installed at all, and there is no guarantee that it is on the path even if it is installed.
Are you sure? AFAIK python points to the default Python, be that 2 or 3.
so, i haven't had this with python, but i have a webserver i manage right now where there are 3 versions of php installed, and `php` as a command returns command not found. This came about when the default version was uninstalled as insecure, but was intentionally not fixed because nothing broke (since fpm managed all of this anyways) and cronjobs were already using the versioned command names and having it error ensures thought is being done into the php version the code runs.

So I do wonder how many distros (and manual install workflows) for python could cause this to happen if python2 got uninstalled from a system that had both, where python get removed, rather then updated to point to python3.

It's the other way around, in all systems I've found. python3 (or python3.x) is the actual executable, with python being a symlink to, usually, python 2.
Sorry, typo. I meant to say `python` is a symlink to the default Python (you can sometimes change the default Python), but it'll almost always exist and point to a valid interpreter.
I think it's inconsistent whether or not `python` exists if you only have python3 installed, depending upon the OS.

This is despite guidance from PEP 0394[1]

1: https://www.python.org/dev/peps/pep-0394/