BUG: `numpy.str_` and `numpy.bytes_` scalars do not support `[()]` indexing despite having `shape == ()`

[andreas-h-sie]

Describe the issue:

numpy.str_ and numpy.bytes_ are 0-dimensional numpy scalars (shape == (), ndim == 0), yet indexing them with [()] (empty tuple, which is the standard way to extract the value from a 0-d array/scalar) raises a TypeError. This is inconsistent with all other numpy scalar types where scalar[()] works correctly.

The issue appears to be that Python's str.__getitem__ / bytes.__getitem__ takes priority over numpy's scalar indexing protocol, interpreting () as a tuple index into the string/bytes sequence rather than as a 0-d array index.

Expected behavior

numpy.str_('hello')[()] should return 'hello' (the Python str value), consistent with how numpy.int64(5)[()] returns 5.

Since numpy.str_ reports shape == () and ndim == 0, it should support the standard 0-d indexing protocol that all other numpy scalars support. Code that generically extracts values from 0-d numpy scalars via val[()] breaks specifically for string and bytes scalars.

Workaround

Use .item() instead of [()]:

np.str_('hello').item()   # => 'hello'  (works)
np.bytes_(b'hello').item()  # => b'hello'  (works)

.item() works consistently across all numpy scalar types.

Reproduce the code example:

import numpy as np

# All other numpy scalar types support [()] indexing:
assert np.int64(5)[()] == 5
assert np.float64(3.14)[()] == 3.14
assert np.bool_(True)[()] == True
assert np.complex128(1+2j)[()] == (1+2j)

# numpy.str_ and numpy.bytes_ do NOT, despite having shape == ():
s = np.str_('hello')
print(f"type: {type(s)}, shape: {s.shape}, ndim: {s.ndim}")  # shape=(), ndim=0

s[()]  # TypeError: string indices must be integers, not 'tuple'

b = np.bytes_(b'hello')
print(f"type: {type(b)}, shape: {b.shape}, ndim: {b.ndim}")  # shape=(), ndim=0

b[()]  # TypeError: byte indices must be integers or slices, not tuple

Error message:

TypeError: string indices must be integers, not 'tuple'



TypeError: byte indices must be integers or slices, not tuple

Python and NumPy Versions:

numpy version: 2.2.6
Python 3.11.2 (main, Aug 26 2024, 07:20:54) [GCC 12.2.0]

Runtime Environment:

No response

How does this issue affect you or how did you find it:

No response

[jorenham]

I can confirm that this also occurs with 2.4.4

[seberg]

While I agree with the sentiment, but I am very doubtful about touching this... (its not a 2.4.4 thing, this is the case since the dawn of time)

Right now these actually inherit from string and bytes and those have their own indexing rules. So... it would be nice, but it is also very unclear what the fallout would be if suddenly string style indexing fails for these.

[AriGood]

That was my reasoning for the gh-31448 . I only added a special case for the empty-tuple index scalar[()], all other indexing is still delegated to the existing Python str/bytes implementation, so the intent was to preserve the current string-style indexing behavior.