Davis Bennett

my first guess, based on the traceback, is that a numpy dtype is getting used in place of a zarr data type.

this looks relevant: https://github.com/zarr-developers/zarr-python/blob/fe42655ae265e045f850e12f30726aa8668d6dde/src/zarr/codecs/sharding.py#L362-L367

i do think it's worth having this issue as indicating either a new cached attribute we need to comment out 😒 or even more reason to fix the underlying issue

@balbasty thank you so much for this work. I think your detective work here will be very much appreciated. general question: why are we doing concatenation at all? is there...

> > general question: why are we doing concatenation at all? is there a reason why we can't statically allocate all the memory we need in advance? I thought the...

looks like a bug in `save_array`. this works if you create a zarr array explicitly: ``` # /// script # requires-python = "==3.12" # dependencies = ["zarr==3.1.2", "numpy"] # ///...

if you don't mind me asking, why are you using `np.bytes_`? the [variable length string dtype](https://zarr.readthedocs.io/en/stable/api/zarr/dtype/index.html#zarr.dtype.VariableLengthUTF8) is generally a better choice

this will work for zarr v2 or v3: ```python # /// script # requires-python = "==3.12" # dependencies = ["zarr==3.1.0", "numcodecs

> zarr v2 and v3 compatible I'm assuming you're talking about zarr-python versions here... why do you need to be compatible with zarr-python 2.x? As far as I know, Zarr...

the underlying bug is not specific to the bytes data type, but rather the fact that the array is 0-dimensional: ```python # /// script # requires-python = "==3.12" # dependencies...