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-120600: Make Py_TYPE() opaque in limited C API 3.14 #120601

Merged
merged 2 commits into from
Jun 18, 2024

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Jun 16, 2024

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/

In the limited C API 3.14 and newer, Py_TYPE() is now implemented as
an opaque function call to hide implementation details.
@vstinner
Copy link
Member Author

cc @encukou @serhiy-storchaka @zooba

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a 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().

@vstinner
Copy link
Member Author

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.

@serhiy-storchaka
Copy link
Member

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().

@vstinner
Copy link
Member Author

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 PyObject.ob_type member, maybe with an atomic operation in Free Threading).

It's not convenient to have to release a reference when using PyObject_Type(), compared to Py_TYPE().

@serhiy-storchaka
Copy link
Member

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.

@vstinner
Copy link
Member Author

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.

@serhiy-storchaka
Copy link
Member

Than what is the point of changing Py_TYPE()? If you do not use the limited C API, you rely on implementation details. If you do not want to rely on them, use PyObject_Type().

@vstinner
Copy link
Member Author

Than what is the point of changing Py_TYPE()?

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.

Copy link
Member

@encukou encukou left a 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.

Misc/stable_abi.toml Show resolved Hide resolved
@serhiy-storchaka serhiy-storchaka removed the request for review from a team June 18, 2024 13:40
Co-authored-by: Petr Viktorin <[email protected]>
@vstinner vstinner enabled auto-merge (squash) June 18, 2024 13:42
@vstinner vstinner merged commit 16f8e22 into python:main Jun 18, 2024
36 checks passed
@vstinner vstinner deleted the stable_abi_type branch June 18, 2024 14:28
picnixz pushed a commit to picnixz/cpython that referenced this pull request Jun 19, 2024
…120601)

In the limited C API 3.14 and newer, Py_TYPE() is now implemented as
an opaque function call to hide implementation details.
mrahtz pushed a commit to mrahtz/cpython that referenced this pull request Jun 30, 2024
…120601)

In the limited C API 3.14 and newer, Py_TYPE() is now implemented as
an opaque function call to hide implementation details.
noahbkim pushed a commit to hudson-trading/cpython that referenced this pull request Jul 11, 2024
…120601)

In the limited C API 3.14 and newer, Py_TYPE() is now implemented as
an opaque function call to hide implementation details.
estyxx pushed a commit to estyxx/cpython that referenced this pull request Jul 17, 2024
…120601)

In the limited C API 3.14 and newer, Py_TYPE() is now implemented as
an opaque function call to hide implementation details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants