Zarr version
commit edd47db
Numcodecs version
Python Version
3.13.3
Operating System
Linux
Installation
uv dev
Description
uv run python
Python 3.13.3 (main, Apr 9 2025, 04:03:52) [Clang 20.1.0 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from zarr.core.dtype.npy.float import Float32
>>> Float32().cast_scalar('NaN')
np.float32(nan)
>>> Float32().cast_scalar('not valid')
Traceback (most recent call last):
File "<python-input-2>", line 1, in <module>
Float32().cast_scalar('not valid')
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/zarr-python/src/zarr/core/dtype/npy/float.py", line 237, in cast_scalar
return self._cast_scalar_unchecked(data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/zarr-python/src/zarr/core/dtype/npy/float.py", line 220, in _cast_scalar_unchecked
return self.to_native_dtype().type(data) # type: ignore[return-value]
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
ValueError: could not convert string to float: 'not valid'
Notice how the above does not produce a TypeError but a ValueError. I don't think this is intended. This actually lets my tests for a "Subarray" dtype fail (via the invalid_scalar_params field), because I pass the check through to the sub-dtype, i.e. return self.subdtype._check_scalar(data).
Steps to reproduce
See above
Additional output
No response
Zarr version
commit edd47db
Numcodecs version
Python Version
3.13.3
Operating System
Linux
Installation
uv dev
Description
Notice how the above does not produce a
TypeErrorbut aValueError. I don't think this is intended. This actually lets my tests for a "Subarray" dtype fail (via theinvalid_scalar_paramsfield), because I pass the check through to the sub-dtype, i.e.return self.subdtype._check_scalar(data).Steps to reproduce
See above
Additional output
No response