-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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-120600: Make Py_TYPE() opaque in limited C API 3.14 #120601
Conversation
In the limited C API 3.14 and newer, Py_TYPE() is now implemented as an opaque function call to hide implementation details.
d9f6361
to
75fada5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is PyObject_Type()
.
I don't understand your remark. Are you suggesting to reimplement Py_TYPE() on top of PyObject_Type()? Py_TYPE() returns a borrowed reference, PyObject_Type() returns a strong reference. |
Py_TYPE was defined as a macro, it depends on the internal structure of PyObject. If you need to use the limited C API, use PyObject_Type() instead of Py_TYPE(). |
Py_TYPE() is very commonly used in C extensions. Having to switch to PyObject_Type() is a lot of work. I don't want to force C extensions maintainers to do that. I only want to hide the implementation details (access to It's not convenient to have to release a reference when using PyObject_Type(), compared to Py_TYPE(). |
Has not C API returning a borrowed reference been frowned upon lately? Strictly speaking, Py_TYPE() is incompatible with Free Threading. If you want to use the limited C API, use PyObject_Type(). If you prefer performance and convenience, use Py_TYPE() and the GIL. |
I don't get it. The stable ABI is guaranteed to be stable. Py_TYPE() is part of the stable ABI. I'm not asking to add it. Only to change its implementation. |
Than what is the point of changing |
As written previously, I am trying to avoid accessing PyObject members directly. This change is part of this project, even if it doesn't disallow accessing PyObject members yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 from me. Even if we can't change the current version of the stable ABI, moving to functions makes sense.
Exposed structs are the one biggest issue with abi4
; if there's ever a new version of a stable ABI, it probably won't have them.
It would be great if modules compiled for the next stable ABI are compatible with 3.14, and at the same time stay API-compatible.
Co-authored-by: Petr Viktorin <[email protected]>
…120601) In the limited C API 3.14 and newer, Py_TYPE() is now implemented as an opaque function call to hide implementation details.
…120601) In the limited C API 3.14 and newer, Py_TYPE() is now implemented as an opaque function call to hide implementation details.
…120601) In the limited C API 3.14 and newer, Py_TYPE() is now implemented as an opaque function call to hide implementation details.
…120601) In the limited C API 3.14 and newer, Py_TYPE() is now implemented as an opaque function call to hide implementation details.
In the limited C API 3.14 and newer, Py_TYPE() and Py_SET_TYPE() are now implemented as opaque function calls to hide implementation details.
📚 Documentation preview 📚: https://cpython-previews--120601.org.readthedocs.build/