[Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Mark Hammond]

On 9/03/2011 5:05 PM, Glenn Linderman wrote:
>
> Standard installation paths are accepted by about 99% of the users, so
> embedding standard installation paths can work well for that batch of
> users. Of course, Windows changes the standard path periodically, so
> that it different from versions prior to and including WinXP versus
> versions after WinXP. And they had no standard before WinNT (or if they
> did, few followed it). Your comment does point out a possible need for
> multiple standard installation paths just for different versions of
> Windows, though :(

The python installer ignores "Program Files" - as much as anything I'm 
concerned about the drive letter - IIUC, Python will default to 
installing on the system drive, which may not be C:

...

> Your premise that using a standard installation path in #@ restricts the
> script to be targeted to one machine is fallacious, so the conclusions
> are also.

Sorry - I should have said "some machines with Python installed by the 
installer".  Contrast this to the option of looking up the registry and 
you have "all machines with Python installed by the installer".  I'm not 
going to quibble about the percentages in the first category as I have 
no data to guide me, but I'm reasonably confident about the "all" in the 
second.

...

> The #! line is clearly is NOT "the only clue Windows needs to make it
> work automagically" or we wouldn't be having this discussion at all.

Sorry - I should have been clear - I meant "the only clue a windows 
specific Python launcher needs".

 > And
> it is not at all clear if a Windows machine contains Jython, IronPython,
> and Cython which one should be launched by a launcher.

I think it is reasonably clear: it would be the same version which would 
be launched on most *nix systems.  Are there any systems where 
"/usr/bin/python" would use Jython, for example?

> You could, of
> course, argue that python-dev is only concerned with CPython, and the
> launcher can be specific to CPython, and that argument might carry the
> day, but the CPython registry lookup necessary to make that happen
> doesn't help the users of alternate implementations a bit, forcing each
> of them to implement their own launcher as well...

I'd have no problem with the Windows launcher supporting other 
implementations - I expect something like "/usr/bin/jython" would be 
reasonable.  How we locate the installed jython is indeed an interesting 
problem, but I'd guess it is surmountable - especially if we can get the 
buy-in of these alternate implementations for their future releases.

> #!/usr/bin/env python2.6
> #@"C:\Program Files\Env.exe" ipy2.6.3.exe

As above, the C: assumes Windows is installed on C: - that may be 
common, but not universal.  Further, a 64bit machine would probably want 
"\Program Files (x86)" (which is becoming more and more common)

>
> in .py files and
>
> #!/usr/bin/env python2.6
> #@"C:\Program Files\Env.exe" ipy2.6.3w.exe
>
> in .pyw files.

I'm slightly skeptical about that - .pyw files are surely rare on *nix 
systems and as we've discussed, pyw files are generally not meant to be 
cmd-line scripts.  IOW, I'm skeptical scripts exist which are meant to 
work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows.

...

> So no matter what is done, it won't solve world hunger. Probably that's
> why Windows users have been left high and dry for years in this
> regard... there is no "system" Python on it, out of the box, so the only
> users are those that are smart enough to download and install and
> configure things, and those who use a Python embedded into an
> application, at the cost of a Python installation per application,
> because there has been no "system" Python, and because Windows users are
> not perceived to be capable of, or willing to bother with, downloading
> and installing various requisite dependencies.
>
> The resulting vacuum has been filled by people with different points of
> view, because there has been no technique implemented, none declared to
> be "best", and anarchy and variant workarounds have abounded.

I'm glad solving world hunger is out of scope for this :)  I understand 
your position but my personal opinion is that simple support for #! is 
more desirable.  I'd be happy to go with the consensus though...

Cheers,

Mark