You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update extending/embedding docs to new way to build modules in C #70702
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2016-03-09.02:43:41.063>labels= ['type-feature', '3.9', 'docs']
title='Update extending/embedding docs to new way to build modules in C'updated_at=<Date2020-12-15.15:36:08.559>user='https://github.com/brettcannon'
Correct usage of multi-phase init might now get users stuck when they start needing per-module state. See PEP-573 "Module State Access from C Extension Methods" for the (hopefully) last thing that prevents me from generally recommending multi-phase init.
That PEP is on my list for after PRP 590 is done.
Before it's implemented, I'm happy leaving PyModuleDef_Init to experts -- that is, have it in the reference docs only.
Changed target version as per Petr's comment (PEP-573 is close to being accepted for 3.9 - it just needs some editing to improve clarity in the PEP itself, rather than needing any changes to the technical proposal)
PEP-630 is now Active. I believe the vast majority of modules can now be ported, and it should be helpful for early adopters (including CPython stdlib). But there are still Open Issues and the API not battle-tested on all the edge cases.
The PEP is written to be easily integrated into official docs when the time comes.
See PEP-573 "Module State Access from C Extension Methods" for the (hopefully) last thing that prevents me from generally recommending multi-phase init.
the perfectionist in me still sees rough edges a few more years (and PEPs) later, but we now have critical mass. Single-phase init is legacy.
Activity
brettcannon commentedon Mar 9, 2016
https://docs.python.org/3/extending/extending.html#a-simple-example uses PyModule_Create() instead of PyModuleDef_Init().
encukou commentedon May 16, 2019
Correct usage of multi-phase init might now get users stuck when they start needing per-module state. See PEP-573 "Module State Access from C Extension Methods" for the (hopefully) last thing that prevents me from generally recommending multi-phase init.
That PEP is on my list for after PRP 590 is done.
Before it's implemented, I'm happy leaving PyModuleDef_Init to experts -- that is, have it in the reference docs only.
ncoghlan commentedon Jan 11, 2020
Changed target version as per Petr's comment (PEP-573 is close to being accepted for 3.9 - it just needs some editing to improve clarity in the PEP itself, rather than needing any changes to the technical proposal)
encukou commentedon Oct 23, 2020
There is now PEP-630. Still not done enough to move it out of draft status, but usable for converting simple modules.
encukou commentedon Dec 15, 2020
PEP-630 is now Active. I believe the vast majority of modules can now be ported, and it should be helpful for early adopters (including CPython stdlib). But there are still Open Issues and the API not battle-tested on all the edge cases.
The PEP is written to be easily integrated into official docs when the time comes.
encukou commentedon Jun 4, 2025
the perfectionist in me still sees rough edges a few more years (and PEPs) later, but we now have critical mass. Single-phase init is legacy.