<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#330033" bgcolor="#ffffff">
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.<br>
<br>
Thanks for starting a PEP.<br>
<br>
On 3/18/2011 11:02 PM, Mark Hammond wrote:<br>
<br>
<blockquote type="cite">
<pre wrap=""> The launcher should be as simple as possible (but no simpler.)
</pre>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:4D8446E0.7030401@skippinet.com.au" type="cite">
<pre wrap=""> * 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.)
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite">
<pre wrap=""> * 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.
</pre>
</blockquote>
<br>
Clarify if environment variables can be used to override semantics
for shebang lines of the form "/usr/bin/python2.x". <br>
<br>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite">
<pre wrap=""> 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'.
</pre>
</blockquote>
<br>
If alternate implementations are to be supported, additional virtual
commands will be required, not just these two. Each one adds
complexity to the launcher.<br>
<br>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
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.<br>
<br>
Within a corporate environment, the system drive, and the Python
installation drive, are likely to be consistent.<br>
<br>
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.<br>
<br>
A Windows #@ could support syntax such as <a class="moz-txt-link-rfc2396E" href="mailto:#@%ProgramFiles%\python3.2\python.exe">"#@
%ProgramFiles%\python3.2\python.exe"</a> 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).<br>
<br>
<br>
</body>
</html>