Skip to content

ENH: Convert flatiter, broadcast and nditer to heap types - #32641

Open
prathamhole14 wants to merge 5 commits into
numpy:mainfrom
prathamhole14:heap_types_iterators
Open

prathamhole14 wants to merge 5 commits into
numpy:mainfrom
prathamhole14:heap_types_iterators

Conversation

@prathamhole14

@prathamhole14 prathamhole14 commented Sep 15, 2026 •

Copy link
Copy Markdown
Member

PR summary

Related to: #31913 as part of adaptation of LIMITED API for _multiarray_umath module
Also related to: #32451 and #32747

AI Disclosure

Ported nditer myself and after getting idea of it (and other changes are almost similar) and mechanical used claude opus 5 extra high to convert to heap type, and verified the code changes myself.

@prathamhole14 prathamhole14 changed the title Heap types iterators ENH: Convert flatiter, broadcast and nditer to heap types Sep 15, 2026
@prathamhole14
prathamhole14 force-pushed the heap_types_iterators branch 2 times, most recently from 77ccd21 to 9e636d2 Compare September 15, 2026 19:15
@prathamhole14
prathamhole14 marked this pull request as ready for review September 16, 2026 04:26
@prathamhole14

Copy link
Copy Markdown
Member Author

Ready for review.

Comment thread numpy/_core/src/multiarray/iterators.c Outdated
api_table[NPY_API_INDEX_PyArrayMultiIter_Type] = state->broadcast_type;
api_table[NPY_API_INDEX_NpyIter_Type] = state->nditer_type;
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we export these types, and CPython errors when creating static types with heap type base classes, I am not sure we can do this yet.

@prathamhole14 prathamhole14 Sep 16, 2026 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, PyType_Ready rejects it and none of these three set Py_TPFLAGS_BASETYPE and neither does ufunc, so the static C route only ever worked because PyType_Ready skips that check.

Maybe BASETYPE is the line to draw here. If a type never claimed to be a base, converting it seems correct.
ndarray, dtype and the scalar types are the real problem and i think they need their own discussion.

Also does this require release note?
Edit: I have added release note

@mattip

mattip commented Sep 22, 2026

Copy link
Copy Markdown
Member

I don't think we can merge this, since it will break any subclassing of these types with static types.

@ikrommyd

Copy link
Copy Markdown
Member

Forgive my ignorance Matti but I was just curious, does numpy subclass those with static types somewhere or are you thinking users might?

@mattip

mattip commented Sep 22, 2026

Copy link
Copy Markdown
Member

Users might, since we export them in the API struct.

@prathamhole14

Copy link
Copy Markdown
Member Author

So would like to know which direction is acceptable.

  1. Adding note in this release that static subclassing of these types is unsupported, then convert them a release later.

  2. Heap types only under Py_LIMITED_API, static types otherwise. I know other folks are not fan of #ifdef Py_LIMITED_API as it means two definitions per type but it's confined to the type definition block and normal builds are untouched. This can go along with the release note from point 1 as well and then in later release we can drop non limited one entirely?

If neither works, then _multiarray_umath can't be built against the Limited API at all, since a static PyTypeObject doesn't compile once Py_LIMITED_API is defined.

@mattip mattip added the triage review Issue/PR to be discussed at the next triage meeting label Sep 23, 2026
@mattip

mattip commented Sep 23, 2026

Copy link
Copy Markdown
Member

I think we should discuss this at a community/triage meeting. In the meantime, can you scan popular github projects for code subclassing these types as static (or for that matter, even heap) types?

@prathamhole14

Copy link
Copy Markdown
Member Author

I searched for this and for the types in this PR no project sets tp_base to PyArrayIter_Type, PyArrayMultiIter_Type, NpyIter_Type or PyUFunc_Type. The ones mentioning them almost all are vendored NumPy headers, NumPy forks or CPython itself.

@mattip

mattip commented Sep 23, 2026

Copy link
Copy Markdown
Member

We discussed this at the community meeting and the general opinion was positive, the probability that anyone is subclassing these is quite small. I will give this one more review pass.

@ikrommyd ikrommyd removed the triage review Issue/PR to be discussed at the next triage meeting label Sep 23, 2026
@mattip

mattip commented Sep 24, 2026

Copy link
Copy Markdown
Member

Other than @ngoldbaum's valid analysis on the performance cost of the change to heap types on #32552, I didn't find any problems here. One thing it might be nice to check is that the assignments of the type in PyArray_API succeed. A good test would be to add to _multiarray_tests.c.src a check that only known slots are NULL, since I don't think we have anything today that does a check. There are some slots that should be NULL, so the test would have to take that into consideration.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants