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

PEP about abi4 etc. (placeholder) #5

Open
gvanrossum opened this issue Oct 10, 2023 · 1 comment
Open

PEP about abi4 etc. (placeholder) #5

gvanrossum opened this issue Oct 10, 2023 · 1 comment

Comments

@gvanrossum
Copy link
Contributor

gvanrossum commented Oct 10, 2023

Sam Gross (@colesbury) has an elaborate proposal for abi4. He's going to draft a PEP.

Things I recall:

  • noGIL builds need PyObject_HEAD to be 32 bytes (it's 16 bytes currently -- all on 64-bit platforms).
  • There's a multi-dimensional compatibility matrix, involving at least the ABI version selected in the source code (Py_LIMITED_API), the wheel's abi tag (abi3 or abi4), the wheel's CPython version tag (e.g. cp312), the CPython version used to build the extension, the CPython used to load the extension.
  • There's a possible hack involving weak linking (Mac/Linux) or "dlsym" (sp?) hacks (Windows).
  • It's easy to get confused by the distinction between the "full" C API and the limited API or the stable ABI. And there's a "full" ABI as well (for "version specific" wheels).
@vstinner
Copy link

I have many ideas how what to put in an abi4. But when it comes to noGIL, I have one request: make PyObject structure empty. The PyObject members would be stored before PyObject* pointer, similar to the internal PyGC_Head structure. It implies to break the backward compatibility since C extensions can currently access directly to PyObject.ob_type and PyObject.ob_refcnt. C extensions would have to go through functions:

  • Py_REFCNT(), Py_SET_REFCNT()
  • Py_TYPE(), Py_SET_TYPE()

The main drawback is that currently, sizeof(PyObject) is leaked into a few places of the abi3:

I'm considering to write a first PEP only to make PyObject opaque: it doesn't imply to make PyObject empty, but only to prevent direct access to PyObject. IMO it's pre-requirement to be able to move PyObject members before PyObject*, to have an ABI which doesn't include PyObject members.

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

No branches or pull requests

2 participants