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

[Mark Hammond]

On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
> On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman<v+python at g.nevcal.com>  wrote:

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

FWIW, the point about Python 2 supporting a -3 arg is explicitly 
mentioned in the PEP.

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

See my reply to Glenn on this - the optional -N.N argument must be the 
first arg, as must the file with the shebang - so if you specify -N.N, 
no shebang processing is done at all.

I expect that in general, the key advantage of shebang parsing will be 
when the script is launched via file association - eg, entering the 
command "foo.py" directly at the command-prompt or double-clicking from 
explorer.  Windows itself will lookup the association and execute 
"py.exe foo.py" - there is no opportunity for the user to arrange for 
arguments to be inserted in that command (only at the tail).

If a user explicitly specifies the command "py.exe -3 foo.py", I 
personally think it is fine the shebang line is ignored as the user has 
expressed a clear intention that a specific version of Python be used.

> 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 reference implementation currently supports 3 environment variables 
- while they have different names, 2 of them work as you describe above. 
  The third is used to nominate how a simple 'python' with no version 
qualifiers should be treated - I wanted the ability for the simple 
'python' to execute a python 3.x version if desired by the user.

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

Thanks for the feedback!

Cheers,

Mark