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

[Sam Partington]

On 17 October 2011 13:23, Mark Hammond <skippy.hammond at gmail.com> wrote:
> On 17/10/2011 9:10 PM, Sam Partington wrote:
>>
>>   "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".

That sounds like an explanation of why it hasn't been implemented
before, not an explanation of why it should continue that way.

In any case, I think that expectation is not complete. In my case it
was my editor that inserted the '-u' on my behalf.

Or why might I not set the default action for .py files to be "py -tt
%1", or "py -3 %1".

Why deny any of the arguments to a pylauncher user?

> * 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?

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.

>> 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.

The PEP is clear yes, but the the help output for the launcher
displays all of the python switches, so I expected them to be
available in the a py.exe call.

>> 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!

The patch does both the bug fix and the arg skipping at present, but
I'll happily separate them if needs be.

Sam