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

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