FR: Allow private runtime config to enable extending without breaking the `PyConfig` ABI

I think? I am running into this issue now as I am trying to embed the Python interpreter using a non c language. I have to stick with the limited API and private structures for configuration in headers files is a no no. Basically, I need to be able to allocate and configure everything using only exportable functions and the heap… no private structure details.

I run into stuff like this:

Hey! Here is a function that is part of the stable ABI and fits your use case! DON’T USE IT! Use this private structure that is not part of the stable ABI and which structure fields and size can be directly tied to a specific python version instead! No offense, but really guys?

I am strictly limited to what’s in the shared library (DLL). I don’t have headers, I can’t statically “recompile” every time a new version of python comes out. That’s unmaintainable for me.

So TLDR… Please for this and in the future, provide opaque heap types with supporting functions that can be part of the Stable ABI within the shared library. Not everybody is trying to embed using C headers and static compilation.

3 Likes