PEP: ?? Title: Python launcher for Windows Version: $Revision$ Last-Modified: $Date$ Author: Mark Hammond Status: Draft Type: Standards Track or Informational ????? Content-Type: text/x-rst Created: 15-Mar-2011 Abstract This PEP describes a Python launcher for the Windows platform. 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. Rationale Unix-like operating systems (referred to simply as "Unix" in this PEP) allow scripts to be executed as if they were executable images by examining the script for a "shebang" line which specified the actual executable to be used to run the script. This is described in detail in the evecve(2) man page [1]. Additionally, these operating systems provide symbolic-links to Python executables in well-known directories. For example, many systems will have a link /usr/bin/python which references a particular version of Python installed under the operating-system. These symbolic links allow Python to be executed without regard for where Python it actually installed on the machine (eg, without requiring the path where Python is actually installed to be referenced in the shebang line or in the PATH. PEP 394 'The "python" command on Unix-Like Systems' [2] describes additional conventions for more fine-grained specification of a particular Python version. These 2 facilities combined allow for a portable and somewhat predictable way of both starting Python interactively and for allowing Python scripts to execute. This PEP describes an implementation of a launcher which can offer the same benefits for Python on the Windows platform. An overview of the launcher. This PEP outlines the general functionality and key guidelines of a launcher for Windows. It is accompianied by reference implemention, written in Python, which defines the detailed implementation. Over time, changes to the implementation may be desired - if the changes adhere to the guidelines in this PEP and have been made following the standard Python development model, this PEP need not change. In other words, this PEP makes no attempt to describe in detail every feature offered by the launcher, but instead to offer guidelines the launcher should adhere to. The actual implementation of the launcher will be written in C and will not link directly or indirectly with Python, but the Python based reference implementation should always remain the canonical description of the functionality. Any changes proposed to the launcher functionality should first be made and agreed to in the Python implementation, after which time the C implementation can be changed to reflect the new reference. Any deviations between the functionality of the reference implementation versus the C implementation due should imply the C implementation is in error. It is expected that 2 versions of the launcher will be needed - one which is a console program and one which is a "windows" (ie, GUI) program. These 2 launchers correspond to the 'python.exe' and 'pythonw.exe' executables which currently ship with Python. The console launcher will be named 'py.exe' and the Windows one named 'pyw.exe'. The "windows" (ie, GUI) version of the launcher will attempt to locate and launch pythonw.exe even if a virtual shebang line nominates simply "python" - infact, the trailing 'w' notation will not be supported in the virtual shebang line at all. The launcher will be distributed with all future versions of Python and if possible, should be installed somewhere likely to already be on the system PATH (eg, the Windows System32) directory. If installed, the "console" version of the launcher should be associated with .py files and the "windows" version associated with .pyw files. The launcher will not be tied to a specific version of Python - eg, a launcher distributed with Python 3.3 should be capable of locating and executing any Python 2.x and Python 3.x version. Future versions of the launcher should remain backwards compatible with older versions, so later versions of Python can install an updated version of the launcher without impacting how the previously installed version of the launcher is used. Guidelines for a Python launcher. The launcher should be as simple as possible (but no simpler.) The Python launcher described in this PEP will intentionally be constrained to the use-cases described in the Rationalle section above. It will not attempt to be a general purpose script launcher or shebang processor and will, in general, limit itself to the features offered by Unix. The launcher should support for format of shebang lines as described in [1], including all restrictions listed. The launcher should support shebang lines commonly found on Unix. For example, a shebang line of '!# /usr/bin/python' should work even though there is unlikely to be an executable in the relative Windows directory "\usr\bin". This means that many scripts can use a single shebang line and be likely to work on both Unix and Windows without modification. The launcher should support fully-qualified paths to executables. While this will make the script inherently non-portable, it is a feature offered by Unix and would be useful for Windows users in some cases. The launcher should be capable of supporting implementations other than CPython, such as jython and IronPython. In particular, if there are common symbolic links used on Unix to specify such an implementation (such as "/usr/bin/jpython", the launcher should support such references on Windows. However, the launcher on Windows need not create its own conventions for use on Windows - ie, if "/usr/bin/jython" is not commonly found on Unix and therefore does not commonly exist in shebang lines, the Windows launcher need not support it. The ability to specify the fully-qualified path to the executable could be used just as it would need to be done on Unix. As the launcher takes the place of Unix symbolic links without using links on Windows, the following concessions will be made: * Environment varialbes will be used to override the semantics for determining exactly what version of Python will be used. For example, while a shebang line of "/usr/bin/python2" will automatically locate a Python 2.x implementation, an environment variable can override exactly which Python 2.x implementation will be chosen. Similarly for "/usr/bin/python" etc. * When used to launch an interactive Python interpreter, the launcher will support the first command-line argument optionally be a version specifier in the form "-n[.n]" (where n is a single integer) to nominate a specific version be used. For example, while "py.exe" may locate and launch the latest Python 2.x implementation installed, a command-line such as "py.exe -3" could specify the latest Python 3.x implementation be launched, while "py.exe -2.6" could specify Python 2.6 be located and launched. If a Python 2.x implementation is desired to be launched with the -3 flag, the command-line would need to be similar to "py.exe -2 -3" (or the specific version of Python could obviously be launched manually without use of this launcher.) While the guidelines above are general, the launcher should make concessions for any Windows specific issues which increase the usefulness of the launcher on Windows. In other words, the guidelines above will not override Windows specific functionality which makes the launcher significantly more useful for Windows users. Shebang lines parsing A shebang line will be parsed according to the rules in [1]. Once parsed, the command will be examined to see if it is a "virtual command". A virtual command starts with either of the 2 strings '/usr/bin/python' or '/usr/bin/env python'. Commands which are virtual are not treated as containing a file-system path, but instead are treated as references to an installed Python. Optionally, the virtual command may include a specific version, such as '/usr/bin/python2' or '/usr/bin/python3.2'. If only a "major version" qualifier is found, the launcher will enumerate the installed Python versions and use the latest minor release found for the major version, which is likely, although not guaranteed, to be the most recently installed version in that family. If major and minor version qualifiers are found, that specific version will be located and used. Note that the "bitted-ness" of Python versions is yet to be considered. While is seems reasonable that a 64bit OS will prefer a matching 64bit version if available, there may also be the requirement to allow this to be explicitly nominated on the shebang line (eg '/usr/bin/python3.2-64'). It may be reasonable to defer this until after a first implementation on the assumption of YAGNI and allow wider feedback to guide future enhancements. If a virtual command has no version specifier, the launcher will attempt to locate a Python 2.x installation and use the latest found. If none are found, it will attempt to use the latest Python 3.x implementation found. The use of 'virtual' shebang lines will be encouraged as this should allow for portable shebang lines to be specified which work on multiple operating systems. If the shebang line is not a virtual one as described above, it is assumed to be a path to an executable - presumably a Python executable, but this will not be checked. No version qualifiers are parsed - if a specific version is required, then the path should reflect that. Releative path specifications will be considered relative to the directory of the launcher. Thus, a shebang line of '#! python' will look for a python executalbe in the same directory as the launcher. Non-virtual shebang lines should be discouraged as they make the script specific to a specific Windows installation. However, they are supported for maximum flexibility. References [1] http://linux.die.net/man/2/execve [2] http://www.python.org/dev/peps/pep-0394/ Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: