Skip to content

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

Open
jorenham wants to merge 1 commit into
numpy:mainfrom
jorenham:typing/flatiter.__next__/fix
Open

TYP: Fix flatiter.__next__ return type for object_ and StringDType#31660
jorenham wants to merge 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],

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

Labels

09 - Backport-Candidate PRs tagged should be backported 41 - Static typing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants