[Python-Dev] PEP397 no command line options to python? (original) (raw)

Mark Hammond skippy.hammond at gmail.com
Tue Oct 18 02:00:27 CEST 2011

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

More information about the Python-Dev mailing list