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 _______________________________________________ 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
