[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

[Mark Hammond]

On 20/03/2011 6:22 PM, Glenn Linderman wrote:
> On 3/19/2011 7:38 PM, Mark Hammond wrote:
...
> A Windows user who has only learned Python 2.x programming would not
> necessarily have ever heard of execve, would not realize execve(2) means
> it is from the 2nd chapter of the Unix man pages, meaning an API call,
> would not know C programming, would not know what #include <unistd.h>
> means, would not understand syntax like "const" or "[]". The description
> is a bit friendlier, if they get that far, but they may still be quite
> confused by wondering how to create and provide argv and envp in the
> right forms, wondering what SIGCHLD, PID, set-user-ID bit, SIG_IGN,
> SIG_DFL, SIGTRAP, set-group-ID, effective id, a.out, binary executable,
> shared library stubs, ld.so(8), ELF executable, PT_INTERP, and
> /lib/ld-unix.so.1 (and .2) are.

Sorry, I didn't mean to imply we would refer people to the execve man 
page, but simply that the man page defines the behaviour from the POV of 
the PEP.

> Ah, but Mark! You are confusing (and maybe I do in some of my comments
> too) the complexity of the launcher versus the complexity of describing
> the launcher.

I believe it will be simple to describe it -as you mention, the execve 
man page needs only a couple of sentences - I believe with just a few 
more it can be documented with the same clarity and quality as the rest 
of the Python docs for Windows users.

> The PEP could therefore be clearer by discussing the CPython
> implementation strategy, even if it points out that other
> implementations may need a different strategy.

I believe it states fairly clearly that the reference implementation 
defines much of this, and the reference implementation I referred to 
does indeed implement (and therefore define) it.  The PEP does make 
mention of other implementations.

> So I think we are agreeing here, mostly. And you mentioned having the
> CPython implementation PythonX.Y get on the PATH somehow. So just keep
> the python launcher off the PATH, remove its then unnecessary option
> syntax, and we agree totally :)

Not quite - my point is that *if* a CPython implementation is on the 
path (which many users arrange), then there is no advantage to using the 
launcher for that specific Python.  I personally don't have any CPython 
implementation on my path (actually, that isn't totally true - cygwin's 
Python is for my command-prompts), and therefore would find the 
behaviour described in the launcher incredibly useful.  This scratches 
my itch and unless the option does harm for people who choose not to use 
it, I see no problem with supporting it.

> Does anyone see any benefit to using a launcher, if PythonX.Y is on the
> PATH? I don't.

Fair enough.  But users who do not have a PythonX.Y on the PATH (even if 
they have another X.Y on it) will.

> Per the beginning of this email, I think you need to stay far away from
> referencing the execve man page in a description of a Windows launcher,
> except perhaps as a footnote.

The PEP is not intended to be user documentation, but if it is to be 
used in that way I'd be happy to document it directly in the PEP.

> Not using the launcher from the command line, and it not having any
> available options, would sidestep this issue nicely.

I don't see what issue needs to be side-stepped.  IMO the feature can be 
clearly described (even if my initial PEP didn't do so) and easily 
avoided if not desired.

> No, the workaround of using fully-qualified executable names in the
> shebang line makes the script now dysfunctional on Unix.

No - as the PEP says, if it can be expected to work on Unix, it should 
be expected to work on Windows.  Otherwise, the script is inherently 
dysfunctional on Unix, so the fully-qualified path is perfectly reasonable.

> I don't think you'll get "always", because of environments that use
> different implementations on different platforms. To get always, you
> need the flexibility to specify implementation and version for each
> platform separately... two lines.

Sorry, but I just don't go for this at all.  Please don't continue to 
advocate for that in a PEP I am sponsoring - just propose your own.

> Let's enumerate... and maybe if we keep talking we'll increase the
> agreement list and decrease the disagreement list.
>
> New ideas in this message:
> 1) If launcher doesn't find a #!/#@ line, it should run python2 to
> support scripts without such lines.

Sorry if the PEP didn't make it clear, but that is how the reference 
implementation works.  You might like to try it.

> Agreements:
> 1) Python needs PythonX.Y to be on the PATH

Nope.

> 2) Need a launcher to handle Windows associations that otherwise only
> allow one version for one extension
> 3) Need a separate launcher for .py and .pyw

Yep.

> 4) Support for as many environments as possible, and as many
> installations as possible for each environment.

Nope - "supports standard Python installations on all Windows 
installations".  Note the "all".

> What else? Can I borrow and tweak your reference implementation?

Please do!

Cheers,

Mark