[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

[Dj Gilcrease]

On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> The launcher could be simpler if the Python installer placed versioned
> Python executables on the PATH.  Unfortunately, historically it hasn't.  If
> it did, would, or the launcher installer would place them there for
> pre-existing versions of Python, then the launcher could work by launching
> the appropriate version of Python, expecting Windows to find it on the
> PATH.  The PEP doesn't address the level of internal complexity of the
> launcher necessary to find where Python has been installed, neither for
> CPython, nor for the alternate implementations to be supported.

The complexity isnt all that much since python has installed Registry
keys in known locations for a long time, it could/would just use these
to locate the proper python version

>
> The launcher could be simpler if a directory  \usr\bin were created under
> Windows Program Files, placed on the PATH, and %ProgramFiles% prepended to
> the Unix #! line, with the Python/Jython/Cython installers placing
> appropriately versioned executables in that directory.  Could even start a
> trend for programs ported from Unix.  One could even place an "env" program
> there, for more simplicity.

This is not about trying to get windows to behave more like *nix in
general it is about allowing python to have interoperability between
windows and unix with well known shebang lines

> I think that a python launcher that is "on the PATH" that could be used to
> launch an interactive Python, should be different than one that is used to
> launch XXXX.py[w] scripts.  The above paragraph raises the issues below,
> which I think are confusing enough to justify this, IMO.  Certainly, if the
> same python launcher is used for both cases, a lot more clarity around
> parameter handling must be provided.

The pep specifically stated that there would be py.exe and pyw.exe

>
> 1) python should be invoked interactively by typing "python" or
> "pythonX[.Y]" at the CMD prompt, not "py".  This can be done without a
> launcher, if appropriate versioned pythons are placed on the PATH.  The
> launcher is really and only needed for handling XXXX.py[w] scripts, which,
> in the Windows way of thinking, can only be associated with one specific,
> system-wide configured version of Python (presently, the latest one wins).
> The script itself is not examined to modify such an association.  The Unix
> !# line provides such modification on Unix.

Adding each version of python to the PATH is not going to happen on
windows the devs have always been resistant to this (A little annoying
yes, but it is what it is)

>
> 2) If the launcher provides command line options for the "benefit" of
> launching interactive Python interpreters, those command line options can
> have data puns with script names, or can conflict with actual Python
> options.  I believe Python 2 already has a -3 option, for example.  And
> Windows users are not trained that "-" introduces an option syntax, but
> rather "/".  Most _programmer_ users would probably be aware of "-" as an
> option syntax, but Python is used as a language for non-programmers in some
> circles, and few Windows non-programmers understand "/" much less "-" and
> not even command lines very well.  So not using a launcher for launching
> interactive Python sidesteps all that: Python itself is introduced and
> taught, and no need to teach about (or even have) launcher options that
> could possibly conflict and confuse, in addition to Python options that may
> conflict with script names already.  (I have seen lots of Windows users use
> leading punctuation characters on filenames to affect sort order and
> grouping of files in My Documents, not knowing they can create
> subdirectories/subfolders, or not wanting to bother with them, since all
> their applications default to opening things from My Documents.)

The command line options I disagree with as well. If the user wants to
test a script that has a shebang of python2 with python3 then they
should explicitly launch it that way just like you would have to do on
*nix

>
> 3) Unix !# lines can have embedded options after the program name on the
> line.  Such options would be another source of potential conflict with
> launcher options, if the launcher has options for use with launching
> interactive interpreters.
>
> Item 3 is also an issue for the PEP even apart from its use as an
> interactive Python launcher; since options may exist on the Unix #! line, a
> discussion of how and if they are handled by the launcher should be included
> in the PEP.

They should be passed exactly as they are on the shebang line

>
>     * Environment varialbes will be used to override the semantics for
>       determining exactly what version of Python will be used.  For
>       example, while a shebang line of "/usr/bin/python2" will
>       automatically locate a Python 2.x implementation, an environment
>       variable can override exactly which Python 2.x implementation will
>       be chosen.  Similarly for "/usr/bin/python" etc.
>
> Clarify if environment variables can be used to override semantics for
> shebang lines of the form "/usr/bin/python2.x".

No I think there should be at max 2 environment variables and they
should be explicitly set by the user not added by default
PYTHON_2
    If set would override the latest version of python2 that is
launched via a shebang line ending in python or python2 but not
python2.x
PYTHON_3
    if set would override the latest version of python3 that is
launched via a shebang line ending in python3 but not python3.x


>
>     The launcher should be capable of supporting implementations other
>     than CPython, such as jython and IronPython.  In particular, if there
>     are common symbolic links used on Unix to specify such an
>     implementation (such as "/usr/bin/jpython", the launcher should
>     support such references on Windows. However, the launcher on Windows
>     need not create its own conventions for use on Windows - ie, if
>     "/usr/bin/jython" is not commonly found on Unix and therefore does
>     not commonly exist in shebang lines, the Windows launcher need not
>     support it. The ability to specify the fully-qualified path to the
>     executable could be used just as it would need to be done on Unix.
>
> I am under the impression that IronPython is a Windows-only implementation,
> but even if it becomes available on Unix via Mono it is certainly possible
> to have Windows-specific implementations.  Apparently the above prevents the
> launcher from launching a Windows-specific implementation not commonly
> available on Unix.

Thats not true it specifically states that the launcher supports fully
qualified path to launch the app so you could do
#! c:\ironpython\ipy.exe

>
>     A shebang line will be parsed according to the rules in [1].  Once
>     parsed, the command will be examined to see if it is a "virtual
>     command".  A virtual command starts with either of the 2 strings
>     '/usr/bin/python' or '/usr/bin/env python'.
>
> If alternate implementations are to be supported, additional virtual
> commands will be required, not just these two.  Each one adds complexity to
> the launcher.

These are the two most common shebang lines on *nix for python. If
there are additional ones that are used in enough distros by default
it would be trivial to add the correct prefixes.

>
> Outside a corporate environment, most Windows system drives, and most Python
> installation drives are both C: and references to "C:\Program Files" are
> highly portable.

This is not true. The default windows installers install to
C:\PythonX.Y and 90% of windows users dont change it.


>
> A Windows #@ could support syntax such as   "#@
> %ProgramFiles%\python3.2\python.exe" where the %-enclosed syntax would be
> looked up in the environment (that is a predefined variable on current
> versions of windows, not sure how far back in history it goes).

No. This is not about adding special functionality on windows it is
about making portable python scripts that just work on most *nix
distros also work and be portable on windows



Thank you Mark for writing up this pep. It is almost identical to the
one I was working up but covers more details and actually provides an
implementation example. Other then the command line args I agree with
everything covered.