> Linux distributions such as Ubuntu [4] and Debian [5] provide more than one Python version at the same time to their users. For example, Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1, with Python 2.6 being the default. [...]
> Because these distributions cannot share pyc files, elaborate mechanisms have been developed to put the resulting pyc files in non-shared locations while the source code is still shared. Examples include the symlink-based Debian regimes python-support [8] and python-central [9]. These approaches make for much more complicated, fragile, inscrutable, and fragmented policies for delivering Python applications to a wide range of users. Arguably more users get Python from their operating system vendor than from upstream tarballs. Thus, solving this pyc sharing problem for CPython is a high priority for such vendors.
> This PEP proposes a solution to this problem.
> Proposal: Python’s import machinery is extended to write and search for byte code cache files in a single directory inside every Python package directory. This directory will be called __pycache__.
Should the package management tool also install multiple versions of the interpreter? conda, mamba, pixi, and uv do. Neither tox nor nox nor pytest care where the python install came from.
And then of course cibuildwheel builds binary wheels for Win/Mac/Lin and manylinux wheels for libc and/or musl libc. repairwheel, auditwheel, delocate, and delvewheel bundle shared library dependencies (.so and DLL) into the wheel, which is a .zip file with a .whl extension and a declarative manifest that doesn't require python code to run as the package installer.
> It includes pure-python replacements for external tools like patchelf, otool, install_name_tool, and codesign, so no non-python dependencies are required.
The launcher first appeared with Python 3.3. There was nothing like the python standalone build project at that point, and `venv` had also just been added to the standard library in the same version.
But it could and should have been redesigned at some point to include those kinds of things, sure. And the second best time to plant a tree is now.
Installations could be managed better on Windows, too. I can envision a cross-platform (rather, made separately available for each major platform) `py` tool which, on Windows, would set up Program Files with the `py` executable in an overall folder (added to PATH), and then subfolders where the actual Python version installations go. NTFS does support hard links and symbolic links (https://en.wikipedia.org/wiki/NTFS_links), so it could conceivably make the executables available directly, too. Then perhaps there could be a `py get` command to grab and run the installer for another version.
On Linux, of course, much the same, but using `/usr/{bin,lib}` in normal ways. Or perhaps `/usr/local/{bin,lib}`. (And the system would come with `py` as well as a specific Python version, and system scripts would have a `py -3.x` shebang.)
