4 ms·

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
      - thaumasiotes 10y ago
        > Why duplicate functionality already available in the shell though? Well, the only reason that functionality is available in the shell is that python is capable of processing python scripts. The shell isn't. So this question doesn't make sense to me. #!/usr/bin/env python3 heading an executable script.py means "when I execute this file, I really mean 'run the command /usr/bin/env python3 script.py", and that means "run the command 'python3 script.py'. And running scripts by invoking python yourself is absolutely standard. Consider "python setup.py install" or, for django, "python manage.py shell".
        sorenjan 10y ago
        The functionality is available in the shell to let you execute scripts without having to know or care what language or version something is written in. That's taken care of by the script author who puts the appropriate shebang in there instead. I'm not suggesting that the shell would execute Python scripts, I'm suggesting that the shell can be used to dispatch the script to the correct Python version. Just like all the other scripting languages. You seem familiar with the concept, so I don't get what's confusing about it. I agree that 'python' should read the shebang when available, at the moment PEP 394 says it should mean 'python2' but is subject to change in the future, but it's easy to solve the problem yourself. Either invoke scripts directly with the ./script.py syntax, or make a script that reads the shebang and uses the right version and then symlink that as 'python' instead.

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
    - thaumasiotes 10y ago
      > Why duplicate functionality already available in the shell though? Well, the only reason that functionality is available in the shell is that python is capable of processing python scripts. The shell isn't. So this question doesn't make sense to me. #!/usr/bin/env python3 heading an executable script.py means "when I execute this file, I really mean 'run the command /usr/bin/env python3 script.py", and that means "run the command 'python3 script.py'. And running scripts by invoking python yourself is absolutely standard. Consider "python setup.py install" or, for django, "python manage.py shell".
      - sorenjan 10y ago
        The functionality is available in the shell to let you execute scripts without having to know or care what language or version something is written in. That's taken care of by the script author who puts the appropriate shebang in there instead. I'm not suggesting that the shell would execute Python scripts, I'm suggesting that the shell can be used to dispatch the script to the correct Python version. Just like all the other scripting languages. You seem familiar with the concept, so I don't get what's confusing about it. I agree that 'python' should read the shebang when available, at the moment PEP 394 says it should mean 'python2' but is subject to change in the future, but it's easy to solve the problem yourself. Either invoke scripts directly with the ./script.py syntax, or make a script that reads the shebang and uses the right version and then symlink that as 'python' instead.