gh-135906: Use _PyObject_CAST in internal CPython headers

[clin1234]

Fixes build errors encountered in python-greenlet/greenlet#450 when building greenlet against CPython 3.14.0b3 free-threaded. Resolves #135906

• Issue: Use _PyObject_CAST in internal headers #135906

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[picnixz]

Please open an issue in this tracker.

[ZeroIntensity]

Please also add a blurb entry, per the bot.

[auvipy]

looks good

[ZeroIntensity]

I see some similar issues elsewhere:

cpython/Include/internal/pycore_freelist.h

Line 88 in 642e5df

PyObject *op = _PyFreeList_PopNoStats(fl);

cpython/Include/internal/pycore_weakref.h

Line 63 in 642e5df

PyObject *obj = FT_ATOMIC_LOAD_PTR(ref->wr_object);

cpython/Include/internal/pycore_weakref.h

Line 90 in 642e5df

PyObject *obj = FT_ATOMIC_LOAD_PTR(ref->wr_object);

Theoretically, we could test for this by including internal headers in test_cppext, but I haven't decided whether I think that's a good idea yet. I'm worried that we're going to be encouraging people to use the private API. Which APIs does Greenlet need?

[clin1234]

I see some similar issues elsewhere:

cpython/Include/internal/pycore_freelist.h

Line 88 in 642e5df

PyObject *op = _PyFreeList_PopNoStats(fl);

cpython/Include/internal/pycore_weakref.h

Line 63 in 642e5df

PyObject *obj = FT_ATOMIC_LOAD_PTR(ref->wr_object);

cpython/Include/internal/pycore_weakref.h

Line 90 in 642e5df

PyObject *obj = FT_ATOMIC_LOAD_PTR(ref->wr_object);

Theoretically, we could test for this by including internal headers in test_cppext, but I haven't decided whether I think that's a good idea yet. I'm worried that we're going to be encouraging people to use the private API. Which APIs does Greenlet need?

This:

https://github.com/python-greenlet/greenlet/blob/b24e39c992e1758032bd913bf7c03d239c29480b/src/greenlet/TGreenlet.hpp#L30-L37

[ZeroIntensity]

Ok. For 3.15, please open an issue requesting that those private APIs be exposed as unstable APIs.

[Fidget-Spinner]

Ok. For 3.15, please open an issue requesting that those private APIs be exposed as unstable APIs.

They don't need to open a new issue. This is a known issue with Cython reporting it as well #130931

[Fidget-Spinner]

I would be happy to merge this (I won't block it). However, we should have some way to make sure we don't regress. pycore_interpframe.h seems to be used by greenlet and Cython which makes it a big enough use case.

[ZeroIntensity]

I think including pycore_interpframe.h (or pycore_interp_structs.h) in test_cppext would work as a good regression test.

[vstinner]

I think including pycore_interpframe.h (or pycore_interp_structs.h) in test_cppext would work as a good regression test.

I wrote test_cppext to test the public C API (headers). Please don't include the internal C API in test_cppext, or add new tests.

[ZeroIntensity]

Hm, why not? Wouldn't it be easier if we were able to catch regressions immediately instead of Cython or Greenlet complaining to us later?

[vstinner]

I mean that I would prefer to leave existing test_cppext unchanged. But you can add new tests on the internal C API if you want.

[vstinner]

I wrote #136247 to test the internal C API in test_cext.

So far, I failed to test the internal C API with C++, I get many compiler errors from mimalloc headers and I'm not sure how to handle them.

[ZeroIntensity]

I think we can ignore mimalloc. Nobody--even Cython--is using that with the internal headers.

[vstinner]

I think we can ignore mimalloc. Nobody--even Cython--is using that with the internal headers.

mimalloc is included indirectly by many internal headers such as pycore_interp.h.

[ZeroIntensity]

This change on its own looks good to me. We'll figure out testing this in #136247.

[vstinner]

LGTM

[miss-islington-app]

Thanks @clin1234 for the PR, and @ZeroIntensity for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

[bedevere-app]

GH-136392 is a backport of this pull request to the 3.14 branch.