PEP 793 – PyModExport: A new entry point for C extension modules

[pitrou (Antoine Pitrou)]

@pablogsal

Given the potential impact of this PEP on the broader Python ecosystem, we would like to gather input from additional communities that will be affected by this, particularly:

• Scientific Python maintainers (NumPy, SciPy, pandas, etc.)
• Other core developers outside the C API WG
• Binding generator maintainers (Cython, pybind11, nanobind, etc.)

As maintainer of PyArrow, I would defer to Cython maintainers as that is what we use for the Python-level scaffolding (we do have C++ code directly calling the CPython API, but it does not create any modules). @scoder @da-woods

However, I have minor comments on the PEP:

• When CPython accepts a pointer where it doesn’t expect to mutate the pointed data, the pointer should be qualified as const (especially when the PEP recommends it point to a static constant)
• The paragraph about the new token mechanism could be clearer. Is the token supposed to be entirely opaque? If so, why is there this weird special case where “when the address of a PyModuleDef is used as a module’s token, the module should behave as if it was created from that PyModuleDef”. Does CPython actually check for that?
• Why PyModule_GetToken? Why not require that module authors always choose their token themselves using the dedicated slot? It seems like one should call PyModule_GetToken in the module exec and then store the token statically… somewhere?
• It would be nice if there was an example of using a module’s token to fetch the module state.
• I would also expect a small subsection about the token mechanism’s performance for accessing module state.