[Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
Mark Hammond
skippy.hammond at gmail.com
Mon Mar 7 23:48:06 CET 2011
On 8/03/2011 7:33 AM, Michael Foord wrote:
> A python launcher as you describe is a *great* idea.
>
> A few concerns:
>
> * we're missing an opportunity to do something easy (Martin is happy to
> modify the installer and says it is easy) for something that may or may
> not happen
Don't let my -0 stop anyone :)
> * will you call it python.exe? will it be installed by the python
> installer?
>
> - I doubt calling it python.exe will fly, but I'm not sure. If so what
> will you call what is currently 'python.exe'? - if not then "python
> foo.py" on the command line will *still* not work...
Calling it python.exe would make the most sense for people who don't
look behind the curtain, but I agree it could potentially be confusing
for people. Further, we would need to ensure we didn't create an
infinite loop where the launcher python.exe found a python.exe it
thought was an appropriate sub-process, but where it turns out it is
actually another launcher.
Having it installed by the Python installer also makes sense to me but
I'd be very interested in Martin's take on this (and also on everything
else we are discussing here).
> * we're (yet again) making instructions for running stuff on Windows
> *different* to other platforms (and making tutorials written for other
> pythons "not work" in certain ways)
Actually, I'd argue we are making them more similar as we would be
honoring a shebang line and allowing the exact same mechanism be used to
denote the major version of Python needed.
> * as I work with multiple platforms it would be really nice if the same
> invocations worked across all of them - whilst I say again that I really
> like the idea of the launcher it doesn't conflict with the other
> suggestions (creating multiple binaries) and as you (Mark) say it
> wouldn't hurt...
>
> So why not do both? We could create the extra binaries to bring Python
> on Windows inline with the unix conventions for command line
> invocations, and the new launcher can follow on as a nice addition.
>
> Note that the discussions about the Python installer adding to the PATH
> won't be *ended* by the creation of the installer. A typical install on
> a Unix-like system adds various other utilities to the path that merely
> adding the top-level of your Python install on Windows still doesn't
> add. In particular distutils installed scripts go into a subdirectory of
> your Python install.
The distutils scripts are a good point. To be honest, apart from the
"file association" issue, I can't see much advantage in doing both - if
all Python directories end up on your path such that "python3 foo.py"
magically works, then the launcher script is adding complexity without
bringing much to the table. Further, I'm somewhat skeptical that the
file associations are used by that many people in the real world -
currently when you double-click on a script you get a temp console
created, and should a traceback be raised, you get to see it for about
2ms before the console is destroyed. Some people may be .pyw to avoid
that, but then their script has to go to extraordinary lengths to
display such errors in a UI of some kind. I suspect most people just
find it more convenient to launch such scripts from a console. Maybe a
quick poll on python-list would be reasonable...
Cheers,
Mark
More information about the Python-Dev
mailing list