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

[Sam Partington]

On 19 October 2011 00:18, Mark Hammond <skippy.hammond at gmail.com> wrote:
> On 18/10/2011 8:59 PM, Sam Partington wrote:
...
>> 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.
>
> Can't you just put the -utt options in the shebang line of build.py?

Yes I can but I didn't.  There are many ways to skin this cat, but I
chose what seemed the most straightforward way.  It went wrong and I
didn't expect it to.  Adding -tt to the shebang line makes sense, the
use of -tt depends on the content of the script (although it would
require me to add -tt to thousands of shebang lines).

But the addition of '-u' depends on the environment in which I want to
run it.  i.e. when run from a console it's unnecessary and a
performance penalty, whilst when run as part of a sub-process (either
from an editor or as part of a larger collection of scripts) then it's
nice to avoid having the output arrive in lumps.

>> 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".
>
> Why would users choose to do that?  Using "python" presumably already works
> for them, so what benefit do they get?  If the main advantage is they can
> now use shebang lines, then the specific options the script wants can be
> expressed in that line.

But "python" does NOT work. If you have multiple pythons installed and
scripts that are designed to run with various versions then 'python'
will use the wrong one, I had thought that this was precisely what
pylauncher was meant to solve, i.e. the ability to select the correct
python version based on the contents of that file.

Nearly all python editors have the ability to run the current script
with python.  None of the editors that I know of have the ability (out
of the box) to parse the shebang line and dispatch to the correct
python.  There is however already a tool that can do that, called
pylauncher. Swap "python" with "py" and it would work in all editors.
The only problem is that it does not support unbuffered output which
nearly all editors will need in order to display timely output.  If
you don't want to support all args, how about just supporting the -u
argument, which is the one I really need?

My issue is currently to select the right python from 2.4, 2.5, 2.6,
2.7. But the need for a tool like this is even stronger when
encouraging users to move to py 3 - on all platforms.  In the absence
of .py3 file extensions the shebang seems the way to go.

"Why would users choose to do that?" : Because they are in a project
using mixed python versions and they want an easy way to use the
correct python from within their editor.

> I wonder if we just need to make it clear that py.exe is not designed to
> simply be a replacement for python.exe - a simple replacement adds no value.
>  It is designed to bring shebang processing to Python on Windows and the
> shebang line is where these args should live.  If you want finer control
> over things, just keep using python.exe.

There I have to disagree.  Yes, a simple replacement would not add
value.  But a replacement that detects the correct python but
otherwise works like python adds lots of value and what is more it has
value on all platforms.

Shouldn't that argument have applied also for the version specifier
args, because to my mind that is a less elegant feature with more
baggage.  (oddity of "py -2 -3" for example).  "If you want finer
control just keep using c:\PythonXX\python.exe".

Incidentally it would be really really nice if the windows installer
installed "pythonX[.Y].exe" then we could just put all the python dirs
in PATH and it would just work. no need for the -X.Y flags at all.

> Also, seeing it is much easier to add a feature later than to remove it, we
> should err on the side of not adding the feature until it is clear that many
> people want it and ensure we aren't creating other inconsistencies or issues
> when we do.  If it turns out to be true that even with clear documentation
> people come to the same conclusion as you (ie, that py.exe supports
> arguments the same way as python.exe) we still have the option of adding it.

Ok ok, I give up.  Apparently I am the only one who wants to be able
to run different versions of python based on the shebang line AND add
occasional arguments to the python command line.

Thanks for listening.

Sam