-
-
Notifications
You must be signed in to change notification settings - Fork 34.4k
gh-142417: Add PyInitConfig_SetInitCallback() function #142420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -238,6 +238,43 @@ Module | |
| Similar to the :c:func:`PyImport_AppendInittab` function. | ||
|
|
||
|
|
||
| Initialization Callback | ||
| ----------------------- | ||
|
|
||
| .. c:function:: int PyInitConfig_SetInitCallback(PyInitConfig *config, PyStatus (*callback)(void *arg), void *arg) | ||
|
|
||
| Set an initialization callback. It allows executing code as soon as the | ||
| Python interpreter is initialized, before the first import. For example, it | ||
| can be used to add a meta path importer into :data:`sys.meta_path`. | ||
|
|
||
| When the callback is called, Python is only partially initialized. What's | ||
| available at this point: | ||
|
|
||
| * Builtin types; | ||
| * Builtin exceptions; | ||
| * Builtin and frozen modules (can be imported); | ||
| * The :mod:`sys` module is only partially initialized | ||
| (ex: :data:`sys.path` and :data:`sys.stdout` don't exist yet). | ||
|
|
||
| After the callback, the Python initialization is completed: | ||
|
|
||
| * Install and configure :mod:`importlib`; | ||
| * Apply the :ref:`Path Configuration <init-path-config>`; | ||
| * Install signal handlers; | ||
| * Finish :mod:`sys` module initialization (ex: create :data:`sys.stdout` | ||
| and :data:`sys.path`); | ||
| * Enable optional features like :mod:`faulthandler` and :mod:`tracemalloc`; | ||
| * Import the :mod:`site` module; | ||
| * etc. | ||
|
|
||
| A single callback can be registered. If this function is called more than | ||
| once, the previous callback is overridden. | ||
|
||
|
|
||
| * Return ``0`` on success. | ||
| * Set an error in *config* and return ``-1`` on error. | ||
|
|
||
| .. versionadded:: next | ||
|
|
||
| Initialize Python | ||
| ----------------- | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| Add :c:func:`PyInitConfig_SetInitCallback` to execute code as soon as the | ||
| Python interpreter is initialized, before the first import. For example, it can | ||
| be used to add a meta path importer into :data:`sys.meta_path`. Patch by Victor | ||
| Stinner. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"executing code as soon as the Python interpreter is initialized"
vs
"Python is only partially initialized. What's available ...:"
two different values of "initialized" here. That's a small list of what is available. Should we bother allowing people to call into Python at all or calling equivalent C Python C APIs from such an API? it feels maybe vaguely defined and hard to support and like something we might change the hyrum's law shape of what is available here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the documentation to:
@gpshead:
Most of the C API is available when the callback is called, including PyRun_SimpleString() high-level function.
@gpshead:
It's vaguely defined on purpose, since the Python runtime is a complex beast, and it's hard to fully described its state while it's being initialized.
What can we do to make such API more future proof?