# Stable ABI/Limited API for free-threaded builds

**URL:** <https://discuss.python.org/t/stable-abi-limited-api-for-free-threaded-builds/86458>\
**Category:** C API\
**Created:** [March 30, 2025, 1:11am UTC](https://discuss.python.org/t/stable-abi-limited-api-for-free-threaded-builds/86458 "2025-03-30T01:11:59Z")\
**Posts on this page:** 1\
**Showing post:** 27

<div class="post-metadata">

**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\
**Post date:** [June 24, 2025, 5:27pm UTC](https://discuss.python.org/t/stable-abi-limited-api-for-free-threaded-builds/86458/27 "2025-06-24T17:27:51Z")

</div>

> [@steve.dower](#):
>
> As I posted earlier, I think `Py_OPAQUE_PYOBJECT` is an unnecessary knob, and we should just rev the API completely.[[1]](#footnote-256936-1)
> 
> The changes behind `Py_OPAQUE_PYOBJECT` are fine, and should be in the next limited API, but no need for an orthogonal flag.

Yes, if we rev the API completely, `Py_OPAQUE_PYOBJECT` will be useless.  
But I’m afraid of making these removals block people from using other 3.15 features.

> [@steve.dower](#):
>
> The way to get me on board with that is to make it _explicitly_ about compile-time warnings/failures without producing different binaries.

Granted!  
`Py_OPAQUE_PYOBJECT` does nothing but hide APIs that are incompatible between regular and free-threaded builds.  
For the record, the preliminary list is:

- `struct _object` (making `PyObject` opaque)
- `struct PyVarObject` (making `PyVarObject` opaque)
- `PyObject_HEAD`
- `_PyObject_EXTRA_INIT`
- `PyObject_HEAD_INIT`
- `PyObject_VAR_HEAD`
- `Py_SIZE` (_can_ be exported as a function instead)
- `Py_SET_TYPE` (_can_ be exported as a function instead)
- `Py_SET_SIZE` (_can_ be exported as a function instead)
- [edited to add]:
  - `PyModuleDef_Base`
  - `PyModuleDef_HEAD_INIT`
  - `PyModuleDef`

* * *

> [@steve.dower](#):
>
> I’d also like to have my [forward-compatible slots](https://github.com/capi-workgroup/api-revolution/issues/4) idea considered

I think your idea ties in nicely with _my_ [forward-compatible slots](https://discuss.python.org/t/pre-pep-unified-slot-system-for-the-c-api/78873/6) idea :‍)

If we do _not_ rev the API completely, these can be added at any point.

---

_[View the full topic](https://discuss.python.org/t/stable-abi-limited-api-for-free-threaded-builds/86458)._