New update to PEP397 - Python launcher for Windows
I've updated PEP 397 - "Python launcher for Windows" based on recent discussions and Vinay's implementation. http://www.python.org/dev/peps/pep-0397/ and a copy is attached for your convenience. The main changes are: * All mentions of the Python reference implementation have been removed now that a C implementation exists and is a more accurate implementation of the PEP than the Python version. * Some "implementation details" have been removed and links added to the launcher docs. This was done mainly so the implementation is free to make changes based on user feedback and still stay true to the PEP. Note that the launcher doc link doesn't exist right now, but should magically appear over the next couple of days as Vinay pushes some changes I just sent him. * The recommendation to install into System32 has been changed to a recommendation to install directly into \Windows, as the System32 directory is not on the default path for 32bit processes on a 64bit Windows. Vinay even has a version of an MSI installer which installs into this directory. The PEP also gives installers more leeway on where to install the launcher if this directory is not writable. I think this PEP is getting close to being finalized - please suggest whatever changes you feel are necessary ASAP as soon I'll be asking for pronouncement. Thanks - especially to Vinay for taking on the C implementation! Mark
On 7/20/2011 11:35 PM, Mark Hammond wrote:
* If the command starts with the definition of a customized command followed by a space character, the customized command will be used. See below for a description of customized commands.
Then a shebang line of '#! vpython' in a script named 'doit.py' will result in the launcher using the command-line 'c:\bin\vpython.exe -foo doit.py'
Shouldn't the second paragraph include a space before the 2nd ' ? In other words, the command as quoted does not show a "customized command followed by a space character" as the definition requires. I don't know why the space character is required, or maybe "white space" was meant, so that the line terminating newline character qualifies also to delimit the customized command?
On 21/07/2011 6:32 PM, Glenn Linderman wrote:
On 7/20/2011 11:35 PM, Mark Hammond wrote:
* If the command starts with the definition of a customized command followed by a space character, the customized command will be used. See below for a description of customized commands.
Then a shebang line of '#! vpython' in a script named 'doit.py' will result in the launcher using the command-line 'c:\bin\vpython.exe -foo doit.py'
Shouldn't the second paragraph include a space before the 2nd ' ? In other words, the command as quoted does not show a "customized command followed by a space character" as the definition requires. I don't know why the space character is required, or maybe "white space" was meant, so that the line terminating newline character qualifies also to delimit the customized command?
Yes, thanks for pointing that out - I've pushed a new version of the PEP with that paragraph reading as: """ If the command starts with the definition of a customized command followed by a whitespace character (including a newline), the customized command will be used. See below for a description of customized commands. """ Thanks, 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/skippy.hammond%40gmail.com
If you're going to include this into standard Python distribution, it needs more attention from _users_. As a user, I can not find any references to any user stories in this PEP article. Abstract chapter is totally useless "This PEP (named 'Python launcher for Windows') describes a Python launcher for the Windows platform." - it is a waste of time to read such stuff. "A Python launcher is a single executable which uses a number of heuristics to locate a Python executable and launch it with a specified command line." - this doesn't answer main questions - Why Launcher is needed, i.e. is there a problem? Can it be solved? How this PEP helps to solve the problem? I see that this launcher is an .msi file. Shouldn't it be portable and don't require administrative privileges? How about KISS? -- anatoly t. On Thu, Jul 21, 2011 at 9:35 AM, Mark Hammond <skippy.hammond@gmail.com> wrote:
I've updated PEP 397 - "Python launcher for Windows" based on recent discussions and Vinay's implementation.
http://www.python.org/dev/peps/pep-0397/ and a copy is attached for your convenience.
The main changes are:
* All mentions of the Python reference implementation have been removed now that a C implementation exists and is a more accurate implementation of the PEP than the Python version.
* Some "implementation details" have been removed and links added to the launcher docs. This was done mainly so the implementation is free to make changes based on user feedback and still stay true to the PEP. Note that the launcher doc link doesn't exist right now, but should magically appear over the next couple of days as Vinay pushes some changes I just sent him.
* The recommendation to install into System32 has been changed to a recommendation to install directly into \Windows, as the System32 directory is not on the default path for 32bit processes on a 64bit Windows. Vinay even has a version of an MSI installer which installs into this directory. The PEP also gives installers more leeway on where to install the launcher if this directory is not writable.
I think this PEP is getting close to being finalized - please suggest whatever changes you feel are necessary ASAP as soon I'll be asking for pronouncement.
Thanks - especially to Vinay for taking on the C implementation!
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/techtonik%40gmail.com
On Jul 21, 2011 7:15 AM, "anatoly techtonik" <techtonik@gmail.com> wrote:
If you're going to include this into standard Python distribution, it needs more attention from _users_. As a user, I can not find any references to any user stories in this PEP article. Abstract chapter is totally useless
"This PEP (named 'Python launcher for Windows') describes a Python launcher for the Windows platform." - it is a waste of time to read such stuff.
"A Python launcher is a single executable which uses a number of heuristics to locate a Python executable and launch it with a specified command line." - this doesn't answer main questions - Why Launcher is needed, i.e. is there a problem? Can it be solved? How this PEP helps to solve the problem?
I see that this launcher is an .msi file. Shouldn't it be portable and don't require administrative privileges? How about KISS?
No. As stated in the title, this is for Windows. It also installs to system directories which is likely the need for admin access.
On 21/07/2011 10:13 PM, anatoly techtonik wrote:
If you're going to include this into standard Python distribution, it needs more attention from _users_. As a user, I can not find any references to any user stories in this PEP article. Abstract chapter is totally useless
Could you please be a little more constructive and offer concrete improvements? Mark
On 7/20/2011 11:35 PM, Mark Hammond wrote:
Virtual commands in shebang lines:
Virtual Commands are shebang lines which start with strings which would be expected to work on Unix platforms - examples include '/usr/bin/python', '/usr/bin/env python' and 'python'. Optionally, the virtual command may be suffixed with a version qualifier (see below), such as '/usr/bin/python2' or '/usr/bin/python3.2'. The command executed is based on the rules described in Python Version Qualifiers below.
I note in passing that '/usr/bin/env python' is hard-coded in the launcher, which conforms to the above documentation. But there is no hard requirement in Unix, if I correctly understand it, that '/usr/bin/env' be separated from 'python' (or whatever) by exactly one space. While I doubt it is frequently used with other than a single space, I think it would be legal to have 2 or 3 or 10 spaces, and maybe even tabs or a mixture, and it would work on Unix... but not in the launcher. It would somewhat complicate the launcher code to have an additional case to check for /usr/bin/env, skip following white space, and then compare to python, but it would be more robust. If it is thought that hard-coding a single space covers most of the uses, it should at least be emphasized in the documentation that only commands of than nature containing a single space will work with the launcher.
Glenn Linderman writes:
I note in passing that '/usr/bin/env python' is hard-coded in the launcher, which conforms to the above documentation.
A single character (space or tab) is also hard-coded in Emacs's python-mode.
But there is no hard requirement in Unix, if I correctly understand it, that '/usr/bin/env' be separated from 'python' (or whatever) by exactly one space.
No, there is no hard requirement; the shebang still is not standardized AFAIK. A single space is probably the most portable choice, however. It would not be hard to allow arbitrary whitespace, but I think documenting the restriction is sufficient.
On 7/20/2011 11:35 PM, Mark Hammond wrote:
Customized Commands:
The launcher will support the ability to define "Customized Commands" in a Windows .ini file (ie, a file which can be parsed by the Windows function GetPrivateProfileString). A section called '[commands]' can be created with key names defining the virtual command and the value specifying the actual command-line to be used for this virtual command.
For example, if an INI file has the contents:
[commands] vpython=c:\bin\vpython.exe -foo
Then a shebang line of '#! vpython' in a script named 'doit.py' will result in the launcher using the command-line 'c:\bin\vpython.exe -foo doit.py'
I experimented, and empirically determined, that a customized command can be of the form [commands] /usr/bin/perl=C:\perl\bin\perl.exe and that this works to launch Unix perl scripts on Windows (successfully, if the perl script is actually portable). This does not contradict the above description, but may be surprising to some. I think it is a good thing. Of course, the extra handling of versions, and locating of corresponding installed versions of things applies only to Python, but some may find uses for launching non-Python programs. This also would work for python programs using non-CPython implementations that may not set the registry in the same way. However, because virtual commands take precedence over Customized Commands, there is no way to override even a specific virtual command to point at a Python other than a CPython. (perhaps some serious registry hacking could make a non-CPython masquerade in the registry as a version of CPython.)
participants (6)
-
anatoly techtonik -
Brian Curtin -
Glenn Linderman -
Mark Hammond -
Mark Hammond -
Stephen J. Turnbull