Repository navigation
Make PyCode_GetFirstFree a PEP-689 unstable API #115756
Description
Activity
PyCode_GetFirstFreewas introduced in PR #100721 (first appeared in 3.12.0a4)The name should be
PyUnstable_Code_GetFirstFree(extra underscore).Reacted by Bogdan Romanyuk and Erlend E. AaslandShouldn't this apply to
PyCode_GetNumFreetoo?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?
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 ;)
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?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?
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.
Reacted by Erlend E. AaslandPing @markshannon
Thank you!
Reacted by Erlend E. Aasland
Originally posted by @markshannon in #115654 (comment)
Linked PRs