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

Make PyCode_GetFirstFree a PEP-689 unstable API #115756

Closed
erlend-aasland opened this issue Feb 21, 2024 · 10 comments
Closed

Make PyCode_GetFirstFree a PEP-689 unstable API #115756

erlend-aasland opened this issue Feb 21, 2024 · 10 comments

Comments

@erlend-aasland
Copy link
Contributor

erlend-aasland commented Feb 21, 2024

It was and it wasn't. We don't really want to expose it, but if we don't then Cython and other C extensions will access the internal fields directly, which is worse.

Now that we have an unstable API, it should probably be part of that.
I'd like all code object C APIs to be unstable, but it's probably too late for that.

Maybe rename it to PyUnstableCode_GetFirstFree?

Originally posted by @markshannon in #115654 (comment)

Linked PRs

@erlend-aasland
Copy link
Contributor Author

erlend-aasland commented Feb 21, 2024

PyCode_GetFirstFree was introduced in PR #100721 (first appeared in 3.12.0a4)

@encukou
Copy link
Member

encukou commented Feb 21, 2024

The name should be PyUnstable_Code_GetFirstFree (extra underscore).

@wrongnull
Copy link
Contributor

wrongnull commented Feb 21, 2024

Shouldn't this apply to PyCode_GetNumFree too?

@vstinner
Copy link
Member

The function is part of Python 3.12 release, and after Python 3.12, you want to downgrade the API to the unstable API in Python 3.13? It sounds too late for me, no?

@erlend-aasland
Copy link
Contributor Author

The function is part of Python 3.12 release, and after Python 3.12, you want to downgrade the API to the unstable API in Python 3.13? It sounds too late for me, no?

I'll leave that for the C API WG ;)

@encukou
Copy link
Member

encukou commented Mar 4, 2024

The function is part of Python 3.12 release, and after Python 3.12, you want to downgrade the API to the unstable API in Python 3.13? It sounds too late for me, no?

Downgrading means that the public name, PyCode_GetFirstFree, will be deprecated, but will be kept until the function's signature/behaviour changes (minimum 2 releases).
Do you think this should not be done?

@vstinner
Copy link
Member

vstinner commented Mar 6, 2024

Do you think this should not be done?

I don't think that it's worth it. If later, the function becomes stable, depending on the Python version, PyCode_GetFirstFree() may be deprecated or not, it sounds unpleasant for a minor issue.

Honestly, just elaborate the documentation to express more clearly the stability contract, no?

@encukou
Copy link
Member

encukou commented Mar 6, 2024

If later, the function becomes stable

I don't think the intention is to ever make it stable. It exposes an implementation detail: free variables follow other ones in a code object.

just elaborate the documentation to express more clearly the stability contract

This is the way to do that.

@vstinner
Copy link
Member

vstinner commented Mar 6, 2024

Ping @markshannon

@encukou
Copy link
Member

encukou commented Mar 20, 2024

Thank you!

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

No branches or pull requests

4 participants