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

[encukou (Petr Viktorin)]

@ilayn

From SciPy point of view, this is not much of a design decision we need to make, just as the multi-phase initialization discussion lead to, if you folks say jump, we’ll jump since we typically don’t know the implications (yet) and so far we have been copy pasting what is provided to us.

Besides, our problems are very rarely at the extension module wrapper code as we typically write it once and forget about it.

Thanks!

@ilayn

Just to give a simple example out in the wild, I have been under the impression that the #ifdef guards are needed to signal for subinterpreters and/or free threading versions

Yeah, that’s a problem. By including those Py_mod_multiple_interpreters and Py_mod_gil flags you’re promising that your codebase behaves a certain way; if you just copy & paste them then you’ll get crashes in edge cases. If you don’t add them, you’ll get safe defaults, and clearer error messages in cases that require them.

@ilayn

However the example code provided PEP 793 is convoluting a lot of things already starting from its top comment section.

I hear you. Sadly, the PEP can’t serve user documentation and porting guide. The “interesting” parts of a typical extension module aren’t affected by this PEP.

@ilayn

However typically each PEP is leaning towards hygiene (“xxx is out of scope of this PEP” is a very common phrase) and a bit underestimating the state of affairs that different PEPs causing some “merge conflicts” as they operate around the same places of the extension module code.

The goal is to put the info you need in documentation, rather than PEPs – those document individual change documents so they have those drawbacks by design.

@ilayn

It seems to me that the folks who are doing one PEP are not really involved in the other (or from outside that is the picture). Or the overseers of these PEPs are not coordinating with end result in mind. I guess I would call this a project management issue. If this is not the case then my apologies in advance as I did not scan every location where discussions being held.

You’re perfectly right. Unfortunately, the project manager would probably also need a crystal ball :‍)
You can have stability now – this API is optional, as are the Py_mod_multiple_interpreters & Py_mod_gil slots, etc. But if you omit them, you’ll not support the latest features.

@ilayn

Also the void* APIs are always a scary thing to have and typically are future grenades. Hence I hope there is enough discussion happened around that choice.

For the tokens? Those should be fine as they’re only used for pointer comparison.
Or for the slots? That’s an existing design, which I’d like to change but I’m worried that it’d mean even more churn.