On 17 October 2011 13:23, Mark Hammond <skippy.hamm...@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 _______________________________________________ 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
