[Python-Dev] PEP397 no command line options to python?

[Mark Hammond]

On 18/10/2011 3:24 AM, PJ Eby wrote:
>
>
> On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington
> <sam.partington at gmail.com <mailto:sam.partington at 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