Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-106320: Remove private _PyCrossInterpreterData API #107068

Closed
wants to merge 1 commit into from

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Jul 22, 2023

Move private _PyCrossInterpreterData API to the internal C API: add a new pycore_cross_interp.h header file.

Mark _PyCrossInterpreterData_Init() and
_PyCrossInterpreterData_Lookup() functions are static.

Move get_crossinterp_data() and restore_crossinterp_data() from _testcapi to _testinternalcapi.

Move private _PyCrossInterpreterData API to the internal C API: add a
new pycore_cross_interp.h header file.

Mark _PyCrossInterpreterData_Init() and
_PyCrossInterpreterData_Lookup() functions are static.

Move get_crossinterp_data() and restore_crossinterp_data() from
_testcapi to _testinternalcapi.
@vstinner
Copy link
Member Author

cc @ericsnowcurrently: FYI

@vstinner vstinner enabled auto-merge (squash) July 22, 2023 21:05
@ericsnowcurrently
Copy link
Member

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

@vstinner
Copy link
Member Author

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?

@vstinner
Copy link
Member Author

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?

@ericsnowcurrently
Copy link
Member

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 the PyUnstable_ 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.

@vstinner
Copy link
Member Author

vstinner commented Jul 24, 2023

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.

@vstinner vstinner closed this Jul 24, 2023
@vstinner vstinner deleted the pycore_cross_interp branch July 24, 2023 21:02
@ericsnowcurrently
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants