Ah no please, don’t take it further than I intended It’s meant as self control not literally but then again it’s strange times to be online so I’ll make it more neutral from now on.
No we do see the benefits, and it’s something we want. I am not familiar with this forum but we don’t mind a bit of push.
It just needs to happen without too much of disruption and back and forth. The maintenance work to keep things compatible across the product (Arch X compilers X PyVersion) is already massive for us and we are hoping that there is consensus at every level. The consensus would be more beneficial to you folks than it is to us.
As an organization with Steering councils, and whatnot, I take no pride in reminding that train has sailed So expectations are high and rightly so in my opinion.
But like I said no harm done, from SciPy’s perspective we would be happy to implement stable API and its implications on C extension modules.
Show token use in the example (multiple people thought it’d help you find a module object, rather than check you have the right one)
Add rejected idea about changing PyModuleDef to no longer be a PyObject.
About the rejected idea: I tried implementing it, and I think it’s a hard-to-support hack. But a part of my attempt now lives in PyModuleDef_Init, as a sanity check that we can remove at any time.
NumPy (Matti Piccus on the mailing list): If I were still developing PyPy, I would groan at the need to support yet another new C-API with its attendant corner cases, but as a NumPy developer I will just go with the flow and do whatever is recommended by the CPython core team. Module initialization is not a prime pain point of the NumPy project right now, and I hope it will not become so due to interpreter changes.
SciPy (Ilhan Polat here: asked on their discourse): “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.”
at the core dev sprint we asked core devs (unfortunately I don’t have exact quotes):
@eric.snow (who’s been involved in the affected area of the import machinery lately): We should do this cleanup regardless of the free-threading benefits.
@colesbury the free-threader: No strong opinion between this and changing PyModuleDef (what I now list as a rejected idea in PEP 793)
Binding generator maintainers
Cython
Stefan Behnel asked about changing PyModuleDef_HEAD_INIT instead.
Da Woods here: “this seems like an acceptable amount of disruption to solve a problem that is blocking freethreading+stable ABI”
PyQt/SIP (Phil Thompson here): “For me, in a nutshell, I don’t care how much disruption there is (or how many more PEPs) so long as it (freethreading + stable ABI) is done for 3.15.”
–
If I may summarize (though I may be biased): compared to either Stable ABI or free-threading, this API isn’t the hard part :)
I might add that Steve – the dissenting voice in the C API WG – is writing his own PEP that currently requires PEP 793.
And will continue to require it, because it’s a good design (and better with the latest changes).
My PEP also schedules it to be added at the same time as we have an entire long-term stable ABI for users to migrate to, so that users can migrate all at once, with absolutely no pressure to migrate now even though it doesn’t buy them anything (and also without putting pressure on us to maintain yet another way to load modules).
I’ll add my late $2c with my NumPy, SciPy and PyWavelets hat on (aligned with what Matti and Ilhan said): we can pretty easily adapt to the proposed changes, and are happy to do so given the benefits. I also don’t have a preference between the two competing proposals - some disruption seems fine, as long as we get to the end goal here.
Your efforts on Stable ABI improvements are much appreciated by the way. Partly prompted by this discussion thread we had some comments on this on the SciPy issue tracker as well. As a result I wrote up a summary at Tracking issue: Stable ABI support · Issue #23791 · scipy/scipy · GitHub. Surprisingly (to me at least) we don’t seem that far off from being able to use the Stable ABI in SciPy, which would be a massive win for maintainability.
On behalf of the Steering Council, I’m pleased to announce that we have decided to accept PEP 793!
Thank you @encukou for the thorough work on this PEP and for engaging extensively with the community, the C API Working Group, and extension maintainers throughout the process.
It’s meant as self control not literally but then again it’s strange times to be online so I’ll make it more neutral from now on.
So expectations are high and rightly so in my opinion.