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

Mark Hammond skippy.hammond at gmail.com
Mon Oct 17 14:23:11 CEST 2011


On 17/10/2011 9:10 PM, Sam Partington wrote:
> Hello all,
>
> I was surprised to see that the excellent pylauncher doesn't do the
> magic shebang processing if you give it any python command line
> options.  e.g. Given
>
> #!/usr/bin/env python2.6
> import sys
> print(sys.executable)
>
> C:\>py test.py
> C:\Python26\python.exe
> C:\>py -utt test.py
> C:\Python27\python.exe
>
> It is spelled out that it shouldn't do so in the pep :
>
>    "Only the first command-line argument will be checked for a shebang line
>     and only if that argument does not start with a '-'."
>
> But I can't really see why that should be the case.  What is the
> rational behind this?

It really is a combination of 2 things:

* The key use-case for the launcher is to be executed implicitly - ie, 
the user types just "foo.py".  In that scenario there is no opportunity 
for the user to specify any args between the name of the executable and 
of the script.  IOW, the expectation is that people will not type "py 
foo.py", but instead just type "foo.py".

* A desire to avoid command-line parsing in the launcher or to make some 
options "more equal" then others.  Eg, you mention later that -c and -m 
should be special, but what about -w or -Q?  What about new options in 
future versions?

> It is very surprising to the user that adding a
> simple option like -tt should change the way the launcher behaves.
> The PEP also states that the launcher should show the python help if
> '-h' is specified :
>
>      "If the only command-line argument is "-h" or "--help", the launcher will
>      print a small banner and command-line usage, then pass the argument to
>      the default Python.  This will cause help for the launcher being printed
>      followed by help for Python itself.  The output from the launcher will
>      clearly indicate the extended help information is coming from the
>      launcher and not Python."
>
> To me that would suggest to end users that they can use any of the
> command line options with the launcher, and they should behave as if
> you had called python directly.

I think the language is fairly clear - only the help options are special 
and no other options will work.

...

> Incidentally whilst implementing this I also noticed a bug in the
> pylauncher whereby the py launcher would incorrectly treat "py t3" as
> a request for python version as if '-3' had been specified.  I have a
> small patch that fixes this and implements the above for pylauncher
> with extra tests if there is interest.

That certainly sounds like a bug and a patch sent to 
https://bitbucket.org/vinay.sajip/pylauncher will be appreciated!

> PS I have been lurking for a while, hello everyone.

Hi and cheers! :)

Mark


More information about the Python-Dev mailing list