You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BUG: Indexing a void array scalar with (...,) does not return an ndarray #32742
Array scalars can be indexed like 0-dimensional arrays: if *x* is an
array scalar,
- ``x[()]`` returns a copy of array scalar
- ``x[...]`` returns a 0-dimensional :class:`ndarray`
from which it can be deduced that x[y] should produce the same output as x[...][y] for any y, including y=(...,). This is indeed how it works with e.g. np.float64:
>>> import numpy as np
>>> x = np.float64(0)
>>> x[(...,)]
array(0.)
>>> x[...][(...,)]
array(0.)
but it is not how it works with void array scalars:
2.5.2
3.12.3 (main, Aug 31 2026, 10:18:26) [GCC 13.3.0]
Runtime Environment:
No response
How does this issue affect you or how did you find it:
I was working on adding type annotations to a library that uses custom dtypes, and I discovered that I could make the annotations consistent with numpy annotations or with runtime behavior but not both.
Activity
jorenham commentedon Sep 21, 2026
Thanks for reporting, and good to more people using static typing :).
This looks more like a runtime issue than a stubs issue to me.
I was able to repro on the current main branch:
According to Astra 6 the problem lies in
voidtype_subscript, where only a bare...is special cased, but not a(...,):numpy/numpy/_core/src/multiarray/scalartypes.c.src
Lines 3138 to 3165 in 84cd9b6
ikrommyd commentedon Sep 21, 2026
I wouldn't like to fix this by adding another special case for the 1-element ellipsis tuple if we can help it.
jorenham commentedon Sep 21, 2026
Why not? Unpacking single-element tuple arguments in
__getitem__is standard practice, as far as I'm aware.ikrommyd commentedon Sep 21, 2026
Well my reasoning was other scalartypes that have no special casing and let
array_subscriptdecide the answer.