Что такое питон launcher
Что такое питон launcher
Python core development news and information.
Monday, July 11, 2011
A Python Launcher For Windows
Mark Hammond (author of pywin32 and long-time supporter of Python on Windows) has written PEP 397, which describes a new launcher for Python on Windows. Vinay Sanjip (author of the standard library logging module) has recently created an implementation of the launcher, downloadable from https://bitbucket.org/vinay.sajip/pylauncher/downloads
Windows users should consider downloading the launcher and testing it, to help the Python developers iron out any remaining issues. The launcher is packaged as a standalone application, and will support currently available versions of Python. The intention is that once the launcher is finalised, it will be included as part of Python 3.3 (although it will remain available as a standalone download for users of earlier versions).
Some Details About the Launcher
The full specification of the behaviour of the launcher is given in PEP 397. To summarise the basic principles:
Simple Usage Instructions
To specify that a script must use Python 2, simply add:
as the first line of the script. (This is a Unix-compatible form. If you don’t need Unix compatibility, #!python2 will do).
If on the other hand, you want to specify that a script must use Python 3, add:
You can also start the Python interpreter using any of the following commands:
For this to work, the py.exe executable must be on your path. This is automatic with the launchsys version of the installer, but the install directory ( C:\Program Files\Python Launcher) must be added manually to PATH with launcher.msi.
Further Reading
The following email threads on python-dev cover some of the key discussions:
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 specifies the actual executable to be used to run the script. This is described in detail in the evecve(2) man page [1] and while user documentation will be created for this feature, for the purposes of this PEP that man page describes a valid shebang line.
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 and therefore allows the launcher to be the executable associated with ‘.py’ files to support multiple Python versions concurrently.
Specification
This PEP specifies features of the launcher; a prototype implementation is provided in [3] which will be distributed together with the Windows installer of Python, but will also be available separately (but released along with the Python installer). New features may be added to the launcher as long as the features prescribed here continue to work.
Installation
The launcher is installed into the Windows directory (see discussion below) if installed by a privileged user. The stand-alone installer asks for an alternative location of the installer, and adds that location to the user’s PATH.
The installation in the Windows directory is a 32-bit executable (see discussion); the standalone installer may also offer to install 64-bit versions of the launcher.
The launcher installation is registered in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\SharedDLLs with a reference counter. It contains a version resource matching the version number of the pythonXY.dll with which it is distributed. Independent installations will overwrite older version of the launcher with newer versions. Stand-alone releases use a release level of 0x10 in FIELD3 of the CPython release on which they are based.
Python Script Launching
The launcher is restricted to launching Python scripts. It is not intended as a general-purpose script launcher or shebang processor.
The launcher supports the syntax of shebang lines as described in [1], including all restrictions listed.
The launcher supports shebang lines referring to Python executables with any of the (regex) prefixes «/usr/bin/», «/usr/local/bin» and «/usr/bin/env *», as well as binaries specified without
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 will 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 will be capable of supporting implementations other than CPython, such as jython and IronPython, but given both the absence of common links on Unix (such as «/usr/bin/jython») and the inability for the launcher to automatically locate the installation location of these implementations on Windows, the launcher will support this via customization options. Scripts taking advantage of this will not be portable (as these customization options must be set to reflect the configuration of the machine on which the launcher is running) but this ability is nonetheless considered worthwhile.
On Unix, the user can control which specific version of Python is used by adjusting the links in /usr/bin to point to the desired version. As the launcher on Windows will not use Windows links, customization options (exposed via both environment variables and INI files) will be used to override the semantics for determining 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» and «/usr/bin/python3». This is specified in detail later in this PEP.
Shebang line parsing
If the first command-line argument does not start with a dash (‘-‘) character, an attempt will be made to open that argument as a file and parsed for a shebang line according to the rules in [1]:
Once parsed, the command will be categorized according to the following rules:
The use of ‘virtual’ shebang lines is encouraged as this should allow for portable shebang lines to be specified which work on multiple operating systems and different installations of the same operating system.
Configuration file
Virtual commands in shebang lines
Customized Commands
For example, if an INI file has the contents:
Python Version Qualifiers
Some of the features described allow an optional Python version qualifier to be used.
A version qualifier starts with a major version number and can optionally be followed by a period (‘.’) and a minor version specifier. If the minor qualifier is specified, it may optionally be followed by «-32» to indicate the 32bit implementation of that version be used. Note that no «-64» qualifier is necessary as this is the default implementation (see below).
If no minor version qualifiers are found, the environment variable PY_PYTHON (where is the current major version qualifier as determined above) can be set to specify the full version. If no such option 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.
Command-line handling
Only the first command-line argument will be checked for a shebang line and only if that argument does not start with a ‘-‘.
If the only command-line argument is «-h» or «—help», the launcher will print a small banner and command-line usage, then pass the argument to the default Python. This will cause help for the launcher being printed followed by help for Python itself. The output from the launcher will clearly indicate the extended help information is coming from the launcher and not Python.
All other arguments will be passed untouched to the child Python process.
Process Launching
The launcher creates a subprocess to start the actual interpreter. See Discussion below for the rationale.
Discussion
It may be surprising that the launcher is installed into the Windows directory, and not the System32 directory. The reason is that the System32 directory is not on the Path of a 32-bit process running on a 64-bit system. However, the Windows directory is always on the path.
The launcher that is installed into the Windows directory is a 32-bit executable so that the 32-bit CPython installer can provide the same binary for both 32-bit and 64-bit Windows installations.
Ideally, the launcher process would execute Python directly inside the same process, primarily so the parent of the launcher process could terminate the launcher and have the Python interpreter terminate. If the launcher executes Python as a sub-process and the parent of the launcher terminates the launcher, the Python process will be unaffected.
Another hurdle is the support for alternative Python implementations using the «customized commands» feature described above, where loading the command dynamically into a running executable is not possible.
Given these considerations, the launcher will execute its command in a child process, remaining alive while the child process is executing, then terminate with the same exit code as returned by the child. To address concerns regarding the termination of the launcher not killing the child, the Win32 Job API will be used to arrange so that the child process is automatically killed when the parent is terminated (although children of that child process will continue as is the case now.) As this Windows API is available in Windows XP and later, this launcher will not work on Windows 2000 or earlier.
References
Copyright
This document has been placed in the public domain.
Do you know the «Python Launcher for Windows»?
Introduction
Summary
If you set the environment correctly, the Python launcher allows you to launch both your Python 2 and Python 3 scripts the same way:
Working from cmd window, you can also left out the py and launch it as if the script were executable:
You can even omit the extension when launching from the cmd console:
or—if you prefer—it allows you to launch the Python application using mouse double-click on the script icon. The version of Python that is to be used for interpreting the script can now be captured inside the script. And this is a good thing.
Unlucky scenario in Windows (compare to Unix-like systems)
First, a bit of Unix evangelism for those who went astray.
Again, the executable file is marked as executable solely by the above mentioned file attribute. No obligatory extensions are forced, no special names are needed. When you type its name on the command line, the Unix-like operating system launches the file. How does the OS knows the way the file should be launched? How does it distinguish a pure binary executable from a shell script, or from a Python script? The answer is hidden in the first two bytes.
What about the Windows? The OS designers still use a magic number (occasionally). When you know how to look inside any executable (*.exe or *.com), you will find MZ in the first two bytes. On the other hand, you will find nothing special in a *.bat. «And I could bet you—poor Windows apple-pie eaters—write nothing like that at all in your Python scripts for Windows! Shame, shame, shame. «
Say where they are, and cause that I may know them;
For great desire constraineth me to learn
If Heaven doth sweeten them, or Hell envenom.
And he: They are among the blacker souls;
A different sin downweighs them to the bottom;
If thou so far descendest, thou canst see them.
(Dante Alighieri, Divine Comedy)
«Let there be light»
Let there be light to illuminate the path to your better Windows Python-programmer future. You use more Python versions in Windows. You know they are installed at:
Say, c:\Python27 and c:\Python32 is in your PATH. Some of your scripts need Python 2.x, some newer scripts need Python 3.x. For working with command line, you have renamed c:\Python32\python.exe to c:\Python32\python3.exe. Then you can launch older scripts as
and newer scripts as
And because you start to use more and more of the newer scripts (for Python 3), you have later renamed c:\Python32\python3.exe to c:\Python32\py.exe. And the life is easier now.
«Hey! Python 3.3 was just released!» And now you have also
immediately renamed to the c:\Python33\py.exe. You have also changed the PATH to prefer the newer Python 3.3.
. and the date of the file is new. It is the time to read the doc: What’s New In Python 3.3.
Что такое python launcher
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
Windows provides «file associations» so an executable can be associated with an extension, allowing for scripts to be executed directly in some contexts (eg., double-clicking the file in Windows Explorer.) Until now, a strategy of «last installed Python wins» has been used and while not ideal, has generally been workable due to the conservative changes in Python 2.x releases. As Python 3.x scripts are often syntactically incompatible with Python 2.x scripts, a different strategy must be used to allow files with a ‘.py’ extension to use a different executable based on the Python version the script targets. This will be done by borrowing the existing practices of another operating system — scripts will be able to nominate the version of Python they need by way of a «shebang» line, as described below.
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 specifies the actual executable to be used to run the script. This is described in detail in the evecve(2) man page [1] and while user documentation will be created for this feature, for the purposes of this PEP that man page describes a valid shebang line.
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 and therefore allows the launcher to be the executable associated with ‘.py’ files to support multiple Python versions concurrently.
While this PEP offers the ability to use a shebang line which should work on both Windows and Unix, this is not the primary motivation for this PEP — the primary motivation is to allow a specific version to be specified without inventing new syntax or conventions to describe it.
Specification
This PEP specifies features of the launcher; a prototype implementation is provided in [3] which will be distributed together with the Windows installer of Python, but will also be available separately (but released along with the Python installer). New features may be added to the launcher as long as the features prescribed here continue to work.
Installation
The launcher comes in 2 versions — 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» — in fact, the trailing ‘w’ notation is not supported in the virtual shebang line at all.
The launcher is installed into the Windows directory (see discussion below) if installed by a privileged user. The stand-alone installer asks for an alternative location of the installer, and adds that location to the user’s PATH.
The installation in the Windows directory is a 32-bit executable (see discussion); the standalone installer may also offer to install 64-bit versions of the launcher.
The launcher installation is registered in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\SharedDLLs with a reference counter. It contains a version resource matching the version number of the pythonXY.dll with which it is distributed. Independent installations will overwrite older version of the launcher with newer versions. Stand-alone releases use a release level of 0x10 in FIELD3 of the CPython release on which they are based.
The launcher is not 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. However, the launcher binaries have a version resource that is the same as the version resource in the Python binaries that they are released with.
Python Script Launching
The launcher is restricted to launching Python scripts. It is not intended as a general-purpose script launcher or shebang processor.
The launcher supports the syntax of shebang lines as described in [1], including all restrictions listed.
The launcher supports shebang lines referring to Python executables with any of the (regex) prefixes «/usr/bin/», «/usr/local/bin» and «/usr/bin/env *», as well as binaries specified without
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 will 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 will be capable of supporting implementations other than CPython, such as jython and IronPython, but given both the absence of common links on Unix (such as «/usr/bin/jython») and the inability for the launcher to automatically locate the installation location of these implementations on Windows, the launcher will support this via customization options. Scripts taking advantage of this will not be portable (as these customization options must be set to reflect the configuration of the machine on which the launcher is running) but this ability is nonetheless considered worthwhile.
On Unix, the user can control which specific version of Python is used by adjusting the links in /usr/bin to point to the desired version. As the launcher on Windows will not use Windows links, customization options (exposed via both environment variables and INI files) will be used to override the semantics for determining 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» and «/usr/bin/python3». This is specified in detail later in this PEP.
Shebang line parsing
If the first command-line argument does not start with a dash (‘-‘) character, an attempt will be made to open that argument as a file and parsed for a shebang line according to the rules in [1]:
Once parsed, the command will be categorized according to the following rules:
The use of ‘virtual’ shebang lines is encouraged as this should allow for portable shebang lines to be specified which work on multiple operating systems and different installations of the same operating system.
If the first argument can not be opened as a file or if no valid shebang line can be found, the launcher will act as if a shebang line of ‘#!python’ was found — ie., a default Python interpreter will be located and the arguments passed to that. However, if a valid shebang line is found but the process specified by that line can not be started, the default interpreter will not be started — the error to create the specified child process will cause the launcher to display an appropriate message and terminate with a specific exit code.
Configuration file
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.
Customized Commands
For example, if an INI file has the contents:
Python Version Qualifiers
Some of the features described allow an optional Python version qualifier to be used.
A version qualifier starts with a major version number and can optionally be followed by a period (‘.’) and a minor version specifier. If the minor qualifier is specified, it may optionally be followed by «-32» to indicate the 32bit implementation of that version be used. Note that no «-64» qualifier is necessary as this is the default implementation (see below).
On 64bit Windows with both 32bit and 64bit implementations of the same (major.minor) Python version installed, the 64bit version will always be preferred. This will be true for both 32bit and 64bit implementations of the launcher — a 32bit launcher will prefer to execute a 64bit Python installation of the specified version if available. This is so the behavior of the launcher can be predicted knowing only what versions are installed on the PC and without regard to the order in which they were installed (ie, without knowing whether a 32 or 64bit version of Python and corresponding launcher was installed last). As noted above, an optional «-32» suffix can be used on a version specifier to change this behaviour.
If no version qualifiers are found in a command, the environment variable PY_PYTHON can be set to specify the default version qualifier — the default value is «2». Note this value could specify just a major version (e.g. «2») or a major.minor qualifier (e.g. «2.6»), or even major.minor-32.
If no minor version qualifiers are found, the environment variable PY_PYTHON (where is the current major version qualifier as determined above) can be set to specify the full version. If no such option 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.
Command-line handling
Only the first command-line argument will be checked for a shebang line and only if that argument does not start with a ‘-‘.
If the only command-line argument is «-h» or «—help», the launcher will print a small banner and command-line usage, then pass the argument to the default Python. This will cause help for the launcher being printed followed by help for Python itself. The output from the launcher will clearly indicate the extended help information is coming from the launcher and not Python.
All other arguments will be passed untouched to the child Python process.
Process Launching
The launcher offers some conveniences for Python developers working interactively — for example, starting the launcher with no command-line arguments will launch the default Python with no command-line arguments. Further, command-line arguments will be supported to allow a specific Python version to be launched interactively — however, these conveniences must not detract from the primary purpose of launching scripts and must be easy to avoid if desired.
The launcher creates a subprocess to start the actual interpreter. See Discussion below for the rationale.
Discussion
It may be surprising that the launcher is installed into the Windows directory, and not the System32 directory. The reason is that the System32 directory is not on the Path of a 32-bit process running on a 64-bit system. However, the Windows directory is always on the path.
The launcher that is installed into the Windows directory is a 32-bit executable so that the 32-bit CPython installer can provide the same binary for both 32-bit and 64-bit Windows installations.
Ideally, the launcher process would execute Python directly inside the same process, primarily so the parent of the launcher process could terminate the launcher and have the Python interpreter terminate. If the launcher executes Python as a sub-process and the parent of the launcher terminates the launcher, the Python process will be unaffected.
However, there are a number of practical problems associated with this approach. Windows does not support the execv* family of Unix functions, so this could only be done by the launcher dynamically loading the Python DLL, but this would have a number of side-effects. The most serious side effect of this is that the value of sys.executable would refer to the launcher instead of the Python implementation. Many Python scripts use the value of sys.executable to launch child processes, and these scripts may fail to work as expected if the launcher is used. Consider a «parent» script with a shebang line of ‘#! /usr/bin/python3’ which attempts to launch a child script (with no shebang) via sys.executable — currently the child is launched using the exact same version running the parent script. If sys.executable referred to the launcher the child would be likely executed using a Python 2.x version and would be likely to fail with a SyntaxError.
Another hurdle is the support for alternative Python implementations using the «customized commands» feature described above, where loading the command dynamically into a running executable is not possible.
The final hurdle is the rules above regarding 64bit and 32bit programs — a 32bit launcher would be unable to load the 64bit version of Python and vice-versa.
Given these considerations, the launcher will execute its command in a child process, remaining alive while the child process is executing, then terminate with the same exit code as returned by the child. To address concerns regarding the termination of the launcher not killing the child, the Win32 Job API will be used to arrange so that the child process is automatically killed when the parent is terminated (although children of that child process will continue as is the case now.) As this Windows API is available in Windows XP and later, this launcher will not work on Windows 2000 or earlier.
В Windows, что такое python launcher ‘py’, что позволяет контролировать-C между группами процессов?
Однако, это не просто переход к текущему процессу – он действительно относится ко всей “группе процессов”, в которой этот процесс является частью.
Если я использую CREATE_NEW_PROCESS_GROUP и запускаю дочерний script с помощью py whatever.py (т.е. используя python launcher, который предположительно эквивалентно запуску python напрямую), то CREATE_NEW_PROCESS_GROUP кажется, не имеет никакого эффекта: CTRL_C_EVENT также влияет на родителя!
How to use Python’s py launcher for Windows
Thinkstock
The Windows version of the Python interpreter can be run from the command line the same way it’s run in other operating systems, by typing python or python3 at the prompt. But there’s a feature unique to the Python edition of Windows that makes it easier to manage multiple installed versions of the Python interpreter—the py launcher.
The py launcher—or just py for short—is a shortcut to all of the installed versions of Python on one’s system. With a command-line switch, you see at a glance all of the Python interpreters you’ve installed, and invoke a specific version of Python, whether 32-bit or 64-bit.
[ Tune into Serdar Yegulalp’s Smart Python video tutorials to learn smart Python tricks in 5 minutes or less ]
Install the py launcher
The py launcher is optionally installed during the setup process when you first install Python on Windows. At one point you’ll be prompted to do so, as per the screenshots shown below. There is no downside to having py installed. You can always run the Python interpreter directly instead, and py doesn’t interfere with other behaviors.
When installing Python on Windows, select the “Customize installation” option during setup.
In the next screen, make sure the “py launcher” option is checked.
When you type py at the command line, the launcher will invoke the current default Python interpreter. py by itself will drop you into the Python REPL, which you can exit as you normally would by typing quit() or Ctrl-Z.
Four examples of the py launcher in action.
Whenever a new version of Python is installed, the py launcher will be updated, as long as the Python version being installed is newer than the py launcher. For instance, if you installed Python 3.8 and then Python 3.9, the latter version would upgrade py. But if you upgraded your Python 3.8 installation afterward, py wouldn’t be touched since the installer would detect the existence of a newer version.
[ Keep up with the latest developments in Python and software development. Subscribe to the InfoWorld First Look newsletter ]
Run Python scripts with the py launcher
If we have the py launcher, we just type:
To select a specific installation of Python, just pass the version as the first element in the argument list. Any arguments provided after the version are passed along as per usual.
Set the default Python for py launcher
If you want to ensure that a given Python instance runs by default when you run py, you can do so in a number of different ways. The methods are evaluated in this order:
Serdar Yegulalp is a senior writer at InfoWorld, focused on machine learning, containerization, devops, the Python ecosystem, and periodic reviews.