[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