cc@ericsnowcurrently: FYI

The API is required by the _xxsubinterpreters module, which should not use the internal C-API.

The API is required by the _xxsubinterpreters module, which should not use the internal C-API.

Why should it not use the internal C API? What is the rationale?

If you consider that it's important that 3rd party projects can use this API, it should be made public. No?

By the way,PEP 684 - A Per-Interpreter GIL got accepted: should these_xx extensions be renamed to have a public name, and be documented?

The API is required by the _xxsubinterpreters module, which should not use the internal C-API.

Why should it not use the internal C API? What is the rationale?

I'm publishing this module on PyPI.

If you consider that it's important that 3rd party projects can use this API, it should be made public. No?

Maybe with thePyUnstable_ prefix.

By the way,PEP 684 - A Per-Interpreter GIL got accepted: should these_xx extensions be renamed to have a public name, and be documented?

_xxsubinterpreters is related to PEP 554 rather than PEP 684.

I'm publishing this module on PyPI.

Oh, I wasn't aware of that, ok :-) That's what I'm trying to discover by removing private functions: see how they are used.

Well, anyone, I prefer to let you decide what do you: do nothing for now (keep the API as private) and decide later, or make some functions public. You might document in a comment in the header file that these functions are exported to be able to be used in 3rd party projects.

Thanks for your feedback, I close my PR.

Thanks!