Stable ABI/Limited API for free-threaded builds

[encukou (Petr Viktorin)]

@steve.dower

As I posted earlier, I think Py_OPAQUE_PYOBJECT is an unnecessary knob, and we should just rev the API completely.[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 idea considered

I think your idea ties in nicely with my forward-compatible slots idea :‍)

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