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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4