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

Sam Partington sam.partington at gmail.com
Tue Oct 18 11:59:26 CEST 2011


On 18 October 2011 08:10, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> Is very unexpected. And to do so silently, without warning will cause
>
> It's only unexpected if you don't read the PEP. From there:
>
> "The launcher may offer some conveniences for Python developers working
> interactively - for example, starting the launcher with no command-line
> arguments will launch the default Python with no command-line arguments.
> Further, command-line arguments will be supported to allow a specific
> Python version to be launched interactively - however, these conveniences
> must not detract from the primary purpose of launching scripts and must
> be easy to avoid if desired."

I read the PEP, but didn't spot that subtelty.I wonder how many other
people will read the PEP, or just think "Oh, I can just replace python
with py" and have it figure out the python to call.

>> real headaches_ for users, *especially* since py -h lists -u as one of
>> the options, it does not say 'here are the python options but you must
>> call PythonXX/python.exe to use them'.
>
> Well, it's easy enough to make that clearer in the help output of py.exe :-)

Indeed, I would say that if nothing else then that should be done

>> [headaches : it did for me as I ended up with a broken build of my app
>> due to different parts of my app built for different pythons.]
>
> Why does the need arise to invoke py.exe in a build system? Why not just reference the Python executable you want directly?

That's rather OT here, but briefly as I can. We have transitioned our
devel branch to py 2.7.  Our stable branches are to remain py 2.6. The
build system (also written in python) starts lots of sub build
commands, (various SCons, make, bash and python). I added shebangs to
all files as appropriate for devel/stable branch, and initially I
changed the python build targets from "python -utt build.py" to
"./build.py" and I lost the -utt functionality which I could live
with. But on some of the windows machines the default action of python
files was to open an editor with the build.py. So I changed it to "py
-utt build.py". Everything seemed fine initially until tests started
to fail which ensued some head scratching.  I actually didn't figure
out what was going on until I noticed that SCiTe was also calling the
wrong python because it also had "py -utt" to run python scripts.
Incidentally, one of my colleagues also discovered the same issue in
his eclipse pydev setup. I also notice that Editra also does "python
-u" by default, and I can imagine lots of users swapping "python" with
"py".

I am well aware that is is by no means a perfect system and I am
working at making it more bulletproof, but as usual there are time
constraints etc.  We will also go through the whole thing again when
wxPython supports python 3. Hopefully I will have solved all these
issues by then :-)

>> To fix this the launcher doesn't need to track all python command line
>> options, only those that take two args.  I don't really see that it
>> will be such a maintenance burden to have the launcher track any new
>> ones.  Python has only two such options after 20 years of development.
>>
>> As for complexity it's less than 10 lines of C.
>
> Plus tests, presumably ... let's see 'em :-)
>
>> That's a cool feature which I'd not really read up on, but that
>> requires a global configuration file change, it's not doable on a per
>> usage basis.
>
> Per usage = interactively, which is more of a "by-the-by" feature for the launcher, the main purpose being to bring shebang-line functionality to Windows.

Fair enough.  I can see that I am asking more of pylauncher than the
unix shebang parser does. But it seems to so nearly do it correctly
that I was surprised that it didn't do what I had assumed it did do.

I find this usage of it so useful in fact that irrespective of whether
the PEP takes on my suggestions I will be using the patched one, and I
will be writing a unix pylauncher to do the same.

Would it not be an idea to have new installations of python actually
install pylauncher as 'python' which then forwards onto the correct
'pythonX.X'.  It would possibly help resolve the whole question of
"Does python invoke python2 or python3" issue.

The patch should be attached. It is of course 20% C and 80% python tests :-)

Sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_arg_skipping.patch
Type: application/octet-stream
Size: 10160 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20111018/38c434d4/attachment-0001.obj>


More information about the Python-Dev mailing list