[Python-Dev] PEP 441 - Improving Python ZIP Application Support (original) (raw)
Paul Moore p.f.moore at gmail.com
Mon Feb 16 17:16:33 CET 2015
- Previous message: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
- Next message: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 15 February 2015 at 18:25, Petr Viktorin <encukou at gmail.com> wrote:
On POSIXy systems the "python3" symlink is created in all venvs. I thought (perhaps naïvely) that Windows doesn't do shebangs natively, so there's some Python-specific mechanism around them, which should handle "python3".
Windows doesn't have "python2" or "python3" commands, just "python". To choose which version you use, set PATH or use an explicit path to the executable.
The launcher offers shebang handling for scripts, and special-cases the following values for Unix compatibility:
#!/usr/bin/env python
#!/usr/bin/python
#!/usr/local/bin/python
They default to the "default Python" which is normally the latest Python 2 version available, but which can be configured by the user. They also support adding an explicit version (python2, python3, python2.7, python3.4, ...)
As far as I know, this is identical behaviour to Unix - even to the incredibly annoying (to me) choice of Python 2 as a default. So I reconfigure the default in my personal settings to Python 3. Unix users can do this too (although it may involve a symlink in a ~/bin directory rather than an ini file change).
I see no reason for the zipapp module to buck the trend that the default Python is "the latest 2.X version unless the user configures it differently themselves". Hence the default of "#!/usr/bin/env python". Certainly that means that users who use the default have to be prepared for the fact that they are subject to user configuration changes, and yes that includes running under either of Python 2 or 3. If you don't like that, force a particular version with -p, and be prepared for the other issues this may cause (user doesn't have that version, for example).
The alternative, I guess, is to have no default and write no shebang unless -p is specified. That matches how .py files work (you have to type the shebang line in if you want it) and works the same way (on Unix, a file without a shebang must be run with an explicit "python" command, and on Windows it uses the default Python via the file type association). Honestly, I'd be happy with this - the Windows experience is identical, and it saves choosing something inappropriate ("in the face of ambiguity, refuse the temptation to guess" :-))
So, the options I see:
- Stick with /usr/bin/env python
- No shebang unless -p is specified
- Unix users come up with a solution which is the same as the above for Windows users, but which suits them better.
I don't see changing the Windows behaviour as an option.
If nobody comes up with anything for (3) I'll take the consensus between (1) or (2). If there's no consensus, I'll pick something. Probably 1, as why change if nobody has a better idea?
One final thought. This issue is no different from shebang lines in .py scripts - the only real difference is that it's easy to see and edit the shebang in a .py script. It may be that what's really needed here is an option for the user to display and update the shebang line in a pyz archive. I'll look at adding that to the PEP, regardless of the conclusion to this debate.
Paul
- Previous message: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
- Next message: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]