On 18/10/2011 3:24 AM, PJ Eby wrote:
On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington
<sam.parting...@gmail.com <mailto:sam.parting...@gmail.com>> wrote:
Yes it is a bit annoying to have to treat those specially, but other
than -c/-m it does not need to understand pythons args, just check
that the arg is not an explicit version specifier. -q/-Q etc have no
impact on how to treat the file.
In fact there's no real need to treat -c differently as it's extremely
unlikely that there is a file that might match. But for -m you can
come up with a situation where if you it gets it wrong. e.g. 'module'
and 'module.py' in the cwd.
I would suggest that it is also unlikely that there will be any future
options would need any special consideration.
What about -S (no site.py) and -E (no environment)? These are needed
for secure setuid scripts on *nix; I don't know how often they'd be used
in practice on Windows. (Basically, they let you isolate a script's
effective sys.path; there may be some use case overlap with virtual envs.
It is worth pointing out that options can be specified directly in the
shebang line - eg, a line like "#! /usr/bin/python -S" in a foo.py works
as expected. What doesn't work is explicitly using a command like:
% py -E foo.py
Using the foo.py above as an example, that would need to result in
spawning Python with both -E and -S options. For my money, that doesn't
seem worthwhile - eg, someone else may have the expectation that
specifying the args to py.exe should override the args on the shebang
line. Then someone else will have different expectations about the
specific order of the args that should be used (eg, compare using
"python -m somemodule -v" versus "python -v -m somemodule". etc.
For these reasons I'm still advocating we don't support such
command-lines, but as usual I'll go with the consensus :)
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
