iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 648: some touch-ups (#1801)

This commit is contained in:
Brett Cannon 2021-02-06 14:30:43 -08:00 committed by GitHub
parent cdfc88bebe
commit 6f091c5969
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 32 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
pep-0648.rst
View File

@ -14,7 +14,7 @@ Post-History: python-ideas: 16th Dec. python-dev: 18th Dec.
Abstract
========
This pep proposes supporting extensible customization of the interpreter, by
This PEP proposes supporting extensible customization of the interpreter by
allowing users to install scripts that will be executed at startup.
Motivation
@ -32,14 +32,15 @@ Limitations of ``pth`` files
If a library needs to perform any customization before an import or that
relates to the general working of the interpreter, they often rely on the
fact that ``pth`` files, which are loaded at startup, can include Python code
that will be executed when the ``pth`` file is evaluated.
fact that ``pth`` files, which are loaded at startup and implemented via the
site module [#site]_, can include Python code that will be executed when the
``pth`` file is evaluated.
Note that ``pth`` files were originally developed to just add additional
directories to ``sys.path``, but they may also contain lines which start
with "import", which will be \``exec\``ed. Users have exploited this feature to
allow the customizations that they needed. See setuptools [#setuptools]_ or
betterexceptions [#betterexceptions]_ as examples.
with "import", which will be passed to ``exec()``. Users have exploited this
feature to allow the customizations that they needed. See setuptools
[#setuptools]_ or betterexceptions [#betterexceptions]_ as examples.
Using ``pth`` files for this purpose is far from ideal for library developers,
as they need to inject code into a single line preceded by an import, making
@ -48,12 +49,12 @@ create a module that performs all actions on import, as done by
betterexceptions [#betterexceptions]_, but the approach is still not really
user friendly.
Additionally, it is also non-ideal for users of the interpreter as if they
want to inspect what is being executed at Python startup they need to review
Additionally, it is also non-ideal for users of the interpreter if they want
to inspect what is being executed at Python startup as they need to review
all the ``pth`` files for potential code execution which can be spread across
all site paths. Most of those pth will be "legit" pth files that just modify
the path, answering the question of "what is changing my interpreter at
startup" a rather complex one.
all site paths. Most of those ``pth`` files will be "legitimate" ``pth``
files that just modify the path, answering the question of "what is changing
my interpreter at startup" a rather complex one.
Lastly, there have been multiple suggestions for removing code execution from
``pth`` files, see [#bpo-24534]_ and [#bpo-33944]_.
@ -66,7 +67,7 @@ in charge of the system and the interpreter. If both the system administrator
and the responsibility of provisioning the interpreter want to add
customizations at the interpreter startup they need to agree on the contents
of the file and combine all the changes. This is not a major limitation
though, and it is not the main driver of this change, but should the change
though, and it is not the main driver of this change. 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. As an
@ -78,16 +79,16 @@ modifications happening on their interpreter.
Benefits of ``__sitecustomize__``
---------------------------------
Having a structured way of injecting custom startup scripts, will allow
supporting in a better way the cases presented above. It will result in both
maintainers and users better experience as detailed, and allow CPython to
deprecate and eventually remove code execution from ``pth`` files, as desired
in the previously mentioned bpos.
Additionally, these solutions provide a unique way to support all use-cases
that before have been fulfilled via the misuse of ``pth`` files,
``sitecustomize.py`` and ``usercustomize.py``. The use of a ``__sitecustomize__``
will allow for packages, tools and system admins to inject scripts that will
be loaded at startups through an easy to understand mechanism.
Having a structured way of injecting custom startup scripts will allow
supporting the cases presented above in a better way. It will result in both
maintainers and users having a better experience as detailed, and allow
CPython to deprecate and eventually remove code execution from ``pth`` files
as desired in the previously mentioned bpos. Additionally, these solutions
provide a unique way to support all use-cases that before have been fulfilled
via the misuse of ``pth`` files, ``sitecustomize.py`` and
``usercustomize.py``. The use of a ``__sitecustomize__`` will allow for
packages, tools and system admins to inject scripts that will be loaded at
startups through an easy-to-understand mechanism.
Rationale
=========
@ -103,8 +104,8 @@ The ``site`` module will expose an option on its main function that allows
listing all scripts that will be executed, which will allow users to quickly
see all customizations that affect an interpreter.
We will also work with build backends on facilitating the installation of
these files.
We will also work with packaging build backends to facilitate the installation
of these files.
Why ``__sitecustomize__``
-------------------------
@ -118,15 +119,15 @@ Disabling start scripts
-----------------------
In some scenarios, like when the startup time is key, it might be desired to
disable this option altogether. Whilst we could have added a new flag to do
so, we think that the already existing flag ``-S`` [#s-flag]_ is already good
enough, as it disables all ``site`` related manipulation. If the flag is
disable this option altogether. Whilst we could add a new flag to do so, we
think that the already existing flag ``-S`` [#s-flag]_ is already good
enough, as it disables all ``site``-related manipulation. If the flag is
passed in, ``__sitecustomize__`` will not be used.
Order of execution
------------------
The scripts in ``__sitecustomize__`` will be executed in alphabetic order
The scripts in ``__sitecustomize__`` will be executed in file name sorted order
after the evaluation of ``pth`` files. We considered executing them in random
order, but that could result in different results depending on how the
interpreter chooses to pick up those files. So even if it won't be a good
@ -315,3 +316,6 @@ References
.. [#reference-implementation]
https://github.com/mariocj89/cpython/tree/pu/__sitecustomize__
.. [#site]
https://docs.python.org/3/library/site.html