Repository navigation
RFC: (optionally) treat PyObject as an opaque struct using heap types for PEP 803 compliance #19479
Description
as reported in #19249 (comment),
All of the types that rely on extending
PyObjectstatically will need to be updated to use heap types.
practically, this means all structs that use the PyObject_HEAD macros.
With the exception of IterParser, from utils/xml/src/iterparse.c, all the stuct in questions (13) live in wcs, and mostly in astropy_wcs.
linked PRs:
Activity
Naveen447-a11y commentedon Mar 23, 2026
Hi , I would like to work on this issue as part of my GSoC preparation.
Could you please assign it to me
neutrinoceros commentedon Mar 23, 2026
@Naveen447-a11y, we do not usually assign issues and this one in particular is not probably not worth your time right now; to be clear, I expect it to be much easier to iterate on this refactor when/if PEP 803 is accepted, and after our build tool chain (
setuptoolsandCythonmost of all) have been adapted. This may happen in the next few weeks, but I don't think it's worth working on it just yet.Naveen447-a11y commentedon Mar 23, 2026
Thanks for the clarification! I understand — I’ll look for other issues to contribute to in the meantime. Please let me know if there are any beginner-friendly tasks I can start with.
sri6792 commentedon Mar 27, 2026
Hi @neutrinoceros! I am srividhya, a GSoC applicant interested in the 'Hardening core stability' project. I have a background in C/C++ and I'm currently researching the transition to heap types and PEP 793 mentioned in #19479. Is there a small, low-priority C-extension file you'd recommend I look at to understand the current implementation better?
neutrinoceros commentedon Mar 27, 2026
Hi @sri6792, thank you for your interest, but as I explained earlier this week, working on this issue isn't a good idea right now.
sri6792 commentedon Mar 28, 2026
Hi @neutrinoceros, thanks for letting me know! I appreciate the guidance. I'll spend the next few days finalizing my proposal and diving deeper into the PEPs. As a huge space enthusiast, I'm really excited about the potential to help harden Astropy's core. Thanks again!
da-woods commentedon Mar 30, 2026
The summary is a little wrong here: you're already using heap-types (that was necessary to use the Stable ABI). What this change should be proposing is to use opaque Python objects.
Personally, I'd also consider guarding it behind on opt-in macro. I'm still worried it's too much of a performance hit to be the default so you may want to be cautious with this.
Also, Cython won't be able to support this before Python 3.14 (I think). That doesn't stop you writing your own code c with opaque objects. But it means you'll likely need a pre-3.14 wheel too.
neutrinoceros commentedon Mar 30, 2026
I'm going for cp311-abi3 + cp315-abi3t for the time being so it's not a problem for us !
neutrinoceros commentedon Mar 30, 2026
of course, I remember that (thanks again for your help getting this done, btw !). I thought that "stucts statically extending
PyObject" already narrowed the scope to the remaining problem area but I'm happy to use the more accurate description you suggested instead ![-]RFC: convert C struct statically extending `PyObject` to heap types[/-][+]RFC: (optionally) treat `PyObject` as an opaque struct using heap types for PEP 803 compliance[/+]neutrinoceros commentedon Sep 29, 2026
re-opening following @da-woods' post-mortem review on #20492
neutrinoceros commentedon Sep 30, 2026
remaining action is to conduct a similar rework as #20504, for every module that was touched by #20492. The current state is technically broken, even though the broken path is never exercised in CI, so I'm marking this as required for astropy 8.1.0