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

[Glenn Linderman]

Not all of the ideas below are complementary to each other, some are 
either or, to allow different thoughts to be inspired or different 
directions to be taken.

Thanks for starting a PEP.

On 3/18/2011 11:02 PM, Mark Hammond wrote:

>      The launcher should be as simple as possible (but no simpler.)

The launcher could be simpler if it isn't used for launching interactive 
interpreters as well as script references via Windows associations (more 
about that after the next quote).

The launcher could be simpler if it just read through the file of its 
first parameter until it finds a line starting with #@ (process as a 
Windows version of Unix #!) or starting without a # (error case).  This 
avoids the need parse such lines.  So in reality, you are not trying to 
make launcher as simple as possible, but rather attempting to make some 
perceived usage case simple, and make the launcher more complex (and 
harder to define, document, and implement) rather than suggesting that 
since Unix and Windows are different, that maybe they should have 
different lines in the script to help launch them.  Remember, the 
typical Windows user is not likely to place a #! line in their scripts 
in the first place, so teaching them what a Unix #! line is, and how the 
parameter after it should be something that Windows doesn't even use, 
and the launcher has to work hard to interpret, is not as simple as 
possible.

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 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.

>      * When used to launch an interactive Python interpreter, the launcher
>        will support the first command-line argument optionally be a
>        version specifier in the form "-n[.n]" (where n is a single
>        integer) to nominate a specific version be used.  For example,
>        while "py.exe" may locate and launch the latest Python 2.x
>        implementation installed, a command-line such as "py.exe -3" could
>        specify the latest Python 3.x implementation be launched, while
>        "py.exe -2.6" could specify Python 2.6 be located and launched.
>        If a Python 2.x implementation is desired to be launched with the
>        -3 flag, the command-line would need to be similar to "py.exe -2
>        -3" (or the specific version of Python could obviously be
>        launched manually without use of this launcher.)

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.

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.

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.)

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.

>      * 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".

>      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.

>      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.

>      Non-virtual shebang lines should be discouraged as they make the
>      script specific to a specific Windows installation. However, they
>      are supported for maximum flexibility.

This is a false statement.  Non-virtual shebang lines do not make a  
script specific to a specific Windows installation, only specific to the 
(often quite large) subset of Windows installations with particular 
characteristics that are reflected in the non-virtual shebang line.  I 
think the major issue here is whether the Python is installed in drive 
C: or some other drive letter; a secondary issue would be if reference 
is made to a 32-bit Python on a 64-bit Windows, which wouldn't port back 
to a 32-bit Windows not having the "Program Files (x86)" path.

Within a corporate environment, the system drive, and the Python 
installation drive, are likely to be consistent.

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.

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).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110319/a3ac3803/attachment-0001.html>