On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman<v+pyt...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
