Hi Mario,
Thank you for submitting PEP 648 (Extensible customizations of the interpreter at startup). The Steering Council has reviewed the PEP and after careful consideration, we have decided to reject the PEP. There are a number of reasons why we have arrived at this decision so we would like to explain our view of the PEP.
After careful analysis of the PEP, it is clear to us that the main focus of the PEP (as stated in the document) is to provide a more clear mechanism for system administrators and tools that repackage the interpreter. The PEP also mentions “some libraries” but we are not actually convinced of the positive impact on the PEP in this regard (see below).
Our main concern is that the improvements proposed in this PEP have a very limited set of use cases and doesn’t really act as a replacement for the library usage of pth files but further complicates the startup sequence with even more things to consider, including the interaction between this mechanism with virtualenvs. This not only incurs a maintenance cost but the danger of further confusion when something is not working or “magic behaviour” is noticed and the user wants to understand where it is coming from.
There is a fundamental relationship between this PEP and pth files. There is a general agreement that **the executable** behaviour of pth files is undesirable and although this PEP doesn’t claim that is tackling this problem directly, it mentions that it addresses some “limitations of pth files”. However, the PEP actually doesn’t provide a mechanism that is intended to substitute or improve the situation regarding the executable use cases of pth files. In particular there are even some incompatibilities between the proposed mechanism and how pth files propagate to virtual environments:
The customizations applied to an interpreter via the new __sitecustomize__ solutions will continue to work when a user creates a virtual environment the same way that sitecustomize.py interacts with virtual environments.
This is a difference when compared to pth files, which are not propagated into virtual environments unless include-system-site-packages is enabled.
If library maintainers have features installed via __sitecustomize__ that they do not want to propagate into virtual environments, they should detect if they are running within a virtual environment by checking sys.prefix == sys.base_prefix. This behavior is similar to packages that modify the global sitecustomize.py.
This is a fundamental difference that shifts the responsibility on how the changes should behave from the user to the library developer, which is a complicated decision as library developers won’t generally know what behaviour is best for the user. At the same time, if libraries add customizations at startup it will “magically” affect created virtual environments which is one of the “surprising” effects of existing pth files.
Apart from pth files, the PEP indeed proposes a more clear and organized way to incorporate changes that otherwise will go into the sitecustomize.py, but on the other hand this is a very specific use case that mainly affects system administrators and repackaging tools. Even in these cases those stakeholders *already* control the sitecustomize.py and they can indeed adopt this mechanism (or any other that suits their needs better) by hardcoding it in their sitecustomize.py. This highlights what is the impact of the benefit compared with the potential cost (including maintenance and complication of the startup sequence). If this PEP were accepted we will have 3 different ways to configure the startup sequence: pth files, sitecustomize.py and __sitecustomize__, including all the possible interactions. The PEP also mentions that:
Should the change happen, it will also improve the situation for these users, as rather than having a sitecustomize.py which performs all those actions, they can have custom isolated files named after the features they want to enhance.
But this is clearly not a feature directed for users because users are not generally supposed to directly install files in the installation directory. Users that wish to configure their startup configuration already have more specific means to do that (such as the PYTHONSTARTUP environment variable and related mechanisms).
Finally, we believe that the PEP lacks concrete use cases and endorsements where this mechanism will make things easier for libraries or important redistributors. Although the PEP mentions some libraries and some situations it doesn’t clearly state what would be the improvements if the PEP were affected nor includes some statements from library authors or repackagers of the interpreter that indicate how this PEP would benefit them.
Thomas.
--