10 ms·

This recommendation should really be updated IMO. `python3` will never see full adoption as long as `python` is reserved for Python 2. I understand the need as

This recommendation should really be updated IMO. `python3` will never see full adoption as long as `python` is reserved for Python 2. I understand the need as a compatibility thing, but at some point the forward-looking cost of distinguishing `python3` exceeds the legacy cost of applications that just say `python` when they mean `python2`.

CJefferson 10y ago
The best option (in my opinion) would be to add a simple way on the first line of a python file to express the language. Then 'python' can read the file, and execute it under the right language. The problem is if we ever switch 'python' to 'python3', then there will be 5 or so years when 'python' becomes unusable, as you won't know on a given machine if it's python2 or python3, and almost no program works on both.
- takluyver 10y ago
  > if we ever switch 'python' to 'python3'... you won't know on a given machine if it's python2 or python3 This kind of already happened. Arch already has Python 3 as 'python', and if you use any of the popular environment tools (virtualenv, pyenv, conda), whichever version of Python you pick when creating an environment will be 'python' inside that env. It's not that big a problem, though. It's quite possible to write code that runs on both Python 2 and 3, and it's surprisingly rare (in my experience) to call unqualified 'python' rather than using an explicit path.
- takeda 10y ago
  There's no need, if you use virtualenv (as you should) you'll get the right version. I really like that I can install command line tools and then just reference: <virtual env>/bin/<tool name> and it will run it with the correct interpreter.
  - CJefferson 10y ago
    That's fine for me and you, but no good for just distributing a script. Then I want to be able to just say to people 'run this script', maybe explain 'chmod +x' to them at best. Every extra step is a pain, and virtual env is a major pain.
    - takeda 10y ago
      I'm not sure what are you talking about, if you use entry_points in setup.py then it will create right entries, set proper permissions and ensure the right python is run. If you use setuptools correctly it is fairly easy to install and run packages e.g.: venv-3.5 my_env my_env/bin/pip install mypackage or if you don't want to publish it to PyPi: venv-3.5 my_env my_env/bin/pip install mypackage.whl
      - CJefferson 10y ago
        I'm talking about ease of use for non-experts. I sometimes send people python scripts, I can just tell them to run it from the command line. I can assume any linux or Mac OS X distro will have some version of python2 installed, so I can just say "run 'python myscript.py'". If I give them your instructions, then from my computer I don't have venv-3.5, or venv. I'm sure they won't either. Standard ubuntu installs don't have virtualenv or pip either, so non-root users have pain installing any of these things.
        takeda 10y ago
        Ok, so you're talking about simple scripts that are contained in a single file, in that case it's possible to simply write a script that works on all versions. I wrote many scripts like this (ok, not all versions but 2.6-3.6), it's really on the developer. I mean even within a single major version there are changes that are incompatible. For example 2.6 doesn't have OrderedDict, doesn't have set comprehension. 3.3 doesn't have asyncio, 3.4 doesn't have async/await, 3.5 doesn't have types annotation for variables etc. So having python2/python3 doesn't really benefit much especially that at this point everyone is moving away from 2.7. Edit: virtualenv is builtin in python since 3.4.
- sorenjan 10y ago
  What's wrong with the standard shebang? #!/usr/bin/env python3
  - thaumasiotes 10y ago
    Python won't read and "execute" that line. The shell does that. So... ./script_in_indeterminate_version.py would work, but python script_in_indeterminate_version.py wouldn't.
    - sorenjan 10y ago
      Yes, that's how I usually do it, although most of the time I'm on Windows. Is there a benefit of executing python directly?
      - thaumasiotes 10y ago
        Most obviously, calling the script as an executable requires you to have execute permissions on it, whereas calling python requires read permissions on the script. More generally, the whole subthread is about the behavior of the command 'python'. Responding to the complaint "I want 'python' to have behavior X" with "it doesn't, so do something different" isn't really appropriate to a discussion of how 'python' should behave.
        sorenjan 10y ago
        Why duplicate functionality already available in the shell though? Maybe I'm missing something, but if you already have write permission on the script and the permission to run python, you might as well make the script executable. They did duplicate this functionality in the Python launcher on Windows [1], but that's 'py', not 'python'. There might be good reasons for not replacing the regular python binary with a launcher on Linux, I don't know. [1] https://docs.python.org/3/using/windows.html#from-a-script https://docs.python.org/3/using/windows.html#from-a-script
        10y ago

CJefferson 10y ago

The best option (in my opinion) would be to add a simple way on the first line of a python file to express the language. Then 'python' can read the file, and execute it under the right language. The problem is if we ever switch 'python' to 'python3', then there will be 5 or so years when 'python' becomes unusable, as you won't know on a given machine if it's python2 or python3, and almost no program works on both.

takluyver 10y ago
> if we ever switch 'python' to 'python3'... you won't know on a given machine if it's python2 or python3 This kind of already happened. Arch already has Python 3 as 'python', and if you use any of the popular environment tools (virtualenv, pyenv, conda), whichever version of Python you pick when creating an environment will be 'python' inside that env. It's not that big a problem, though. It's quite possible to write code that runs on both Python 2 and 3, and it's surprisingly rare (in my experience) to call unqualified 'python' rather than using an explicit path.
takeda 10y ago
There's no need, if you use virtualenv (as you should) you'll get the right version. I really like that I can install command line tools and then just reference: <virtual env>/bin/<tool name> and it will run it with the correct interpreter.
- CJefferson 10y ago
  That's fine for me and you, but no good for just distributing a script. Then I want to be able to just say to people 'run this script', maybe explain 'chmod +x' to them at best. Every extra step is a pain, and virtual env is a major pain.
  - takeda 10y ago
    I'm not sure what are you talking about, if you use entry_points in setup.py then it will create right entries, set proper permissions and ensure the right python is run. If you use setuptools correctly it is fairly easy to install and run packages e.g.: venv-3.5 my_env my_env/bin/pip install mypackage or if you don't want to publish it to PyPi: venv-3.5 my_env my_env/bin/pip install mypackage.whl
    - CJefferson 10y ago
      I'm talking about ease of use for non-experts. I sometimes send people python scripts, I can just tell them to run it from the command line. I can assume any linux or Mac OS X distro will have some version of python2 installed, so I can just say "run 'python myscript.py'". If I give them your instructions, then from my computer I don't have venv-3.5, or venv. I'm sure they won't either. Standard ubuntu installs don't have virtualenv or pip either, so non-root users have pain installing any of these things.
      - takeda 10y ago
        Ok, so you're talking about simple scripts that are contained in a single file, in that case it's possible to simply write a script that works on all versions. I wrote many scripts like this (ok, not all versions but 2.6-3.6), it's really on the developer. I mean even within a single major version there are changes that are incompatible. For example 2.6 doesn't have OrderedDict, doesn't have set comprehension. 3.3 doesn't have asyncio, 3.4 doesn't have async/await, 3.5 doesn't have types annotation for variables etc. So having python2/python3 doesn't really benefit much especially that at this point everyone is moving away from 2.7. Edit: virtualenv is builtin in python since 3.4.
sorenjan 10y ago
What's wrong with the standard shebang? #!/usr/bin/env python3
- thaumasiotes 10y ago
  Python won't read and "execute" that line. The shell does that. So... ./script_in_indeterminate_version.py would work, but python script_in_indeterminate_version.py wouldn't.
  - sorenjan 10y ago
    Yes, that's how I usually do it, although most of the time I'm on Windows. Is there a benefit of executing python directly?
    - thaumasiotes 10y ago
      Most obviously, calling the script as an executable requires you to have execute permissions on it, whereas calling python requires read permissions on the script. More generally, the whole subthread is about the behavior of the command 'python'. Responding to the complaint "I want 'python' to have behavior X" with "it doesn't, so do something different" isn't really appropriate to a discussion of how 'python' should behave.
      - sorenjan 10y ago
        Why duplicate functionality already available in the shell though? Maybe I'm missing something, but if you already have write permission on the script and the permission to run python, you might as well make the script executable. They did duplicate this functionality in the Python launcher on Windows [1], but that's 'py', not 'python'. There might be good reasons for not replacing the regular python binary with a launcher on Linux, I don't know. [1] https://docs.python.org/3/using/windows.html#from-a-script https://docs.python.org/3/using/windows.html#from-a-script
        10y ago