Alexandros Karypidis <kary...@gmail.com> added the comment:

I think this situation is not ideal and the limitation seems artificial.

If I understand correctly, there are two parameters that govern the behaviour 
of the python launcher:

1) Is the shebang using /usr/bin/env or not?
2) IS the shebang specifying a version qualifier or not?

There are 4 combinations available:

a) env with version qualifier
b) env without version qualifier
c) non-env with version qualifier
d) non-env without version qualifier

Of the above, the python launcher supports (b) and (d).

For case (c) the launcher is configurable with py.ini

For case (a) it was decided to treat it as case (b) and search for "python.exe" 
in the path. To quote:

In the case of (1) I read:

"The launcher also looks for the specific shebang line #!/usr/bin/env python. 
On Unix, the env program searches for a command on $PATH and runs the command 
so located. Similarly, with this shebang line, the launcher will look for a 
copy of python.exe on the user's current %PATH% and will run that copy.

As activating a virtualenv means that it is added to PATH, no special handling 
is needed to run scripts with the active virtualenv - they just need to use the 
#!/usr/bin/env python shebang line, exactly as on Unix. (If there is no 
activated virtualenv, and no python.exe on PATH, the launcher will look for a 
default Python exactly as if the shebang line had said #!python)."

Why does the launcher search for "python.exe" specifically when using a version 
qualifier with env? This is very different to what happens on UNIX and causes 
the issues I reported. I see no reason why using #!/usr/bin/evn pythonX where X 
is a major version should not check the PATH for that specific version (e.g. 
#!/usr/bin/evn python3 should check for python3.exe in the PATH) and only fall 
back to plain "python.exe" if no match is found. This would be much closer to 
UNIX behaviour and allow for "common" shebangs across Windows/Linux/Darwin etc.

I would also note that if I create a python2 virtual environment and use a 
#!/usr/bin/env python3 shebang, a search on the path for python.exe would yield 
the version 2 executable from the virtual environment folder. So the argument 
about there being a technical issue is anyway true (the same wrong thing can 
happen in the current implementation).

Do you have any suggestion on how to work around this limitation using the 
current implementation of python launcher? Is there any way to use 
#!/usr/bin/env python3 across both Windows and non-Windows?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to