Skip to content

TYP: Fix flatiter.__next__ return type for object_ and StringDType - #31660

Merged
charris merged 1 commit into
numpy:mainfrom
jorenham:typing/flatiter.__next__/fix
Jun 24, 2026
Merged

charris merged 1 commit into
numpy:mainfrom
jorenham:typing/flatiter.__next__/fix

Conversation

@jorenham

Copy link
Copy Markdown
Member

PR summary

While working on librosa/librosa#2052, a new mypy error popped up, complaining that the iterated values of ndarray.flat for an object_ array aren't subscriptable, because np.object_ does not support __getitem__. In reality, np.object_ values are pure fiction, so it flatiter.__next__ should instead return Any for object_ arrays.

This also special-cases flatiter.__next__ for StringDType arrays, which have no numpy scalar type, and would yield builtins.str instead.

AI Disclosure

No AI

@jorenham jorenham added 09 - Backport-Candidate PRs tagged should be backported 41 - Static typing labels Jun 16, 2026
self: flatiter[NDArray[ScalarT]], /
) -> ScalarT: ...
@overload # `StringDType` has no scalar type
def __next__(self: flatiter[np.ndarray[Any, np.dtypes.StringDType]], /) -> str: ...

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.

Do you want to care about the fact that accessing a StringDType array can return the na_object as well?

>>> import numpy as np
>>> flt = np.array(["x", None], dtype=np.dtypes.StringDType(na_object=None)).flat
>>> flt[0]
'x'
>>> flt[1]
>>> flt[1] is None
True

It looks like this pattern occurs elsewhere (ndarray.item, ndarray.__iter__, ndarray.tolist, and flatiter.__getitem__(int) to name a few) so feel free to disregard this for now and do a fix focused on that later.

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.

Do you want to care about the fact that accessing a StringDType array can return the na_object as well?

Part of me does, but I'm also a bit worried that doing so will set a precedent where we'll have to add special-casing for this all over the place. So I'm not sure if that's the way we want to go, given that the stubs are already a big mess.
But on the other hand, the stubs are already a big mess, so the ∂mess/∂code probably won't be very high.

In the stubs StringDType is already generic on the na object type, so at least that part is already possible:

Generic[_NaObjectT_co],

@charris
charris merged commit db2a284 into numpy:main Jun 24, 2026
15 checks passed
@charris

charris commented Jun 24, 2026

Copy link
Copy Markdown
Member

Thanks Joren.

@jorenham
jorenham deleted the typing/flatiter.__next__/fix branch June 24, 2026 16:38
@charris charris added 41 - Static typing and removed 41 - Static typing 09 - Backport-Candidate PRs tagged should be backported labels Jul 2, 2026
charris pushed a commit that referenced this pull request Jul 2, 2026
charris added a commit that referenced this pull request Jul 2, 2026
TYP: Fix ``flatiter.__next__`` return type for ``object_`` and `StringDType` (#31660)
@charris charris added 09 - Backport-Candidate PRs tagged should be backported and removed 09 - Backport-Candidate PRs tagged should be backported labels Jul 10, 2026
ngoldbaum pushed a commit to ngoldbaum/numpy that referenced this pull request Sep 8, 2026
ngoldbaum pushed a commit to ngoldbaum/numpy that referenced this pull request Sep 8, 2026
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