• a lazy array indexing API.
  I actually think this will unlock some performance improvements in our array IO.

Is that the same as array "views"? I would be a fan of that

• removeStorePath, give all of its methods to theStore classes

What is the rationale for that? I think it is quite useful to have a pointer to a file (or even byte range) in a store.

Is that the same as array "views"? I would be a fan of that

Yeah, we could think of it like "views" but I think the more basic analogy is with the semantics of slicing generic collections. When you slice into a tuple, you get another tuple, not a numpy array. Zarr should follow the same principle. In concrete terms this would require modelling a zarr array as supported by a collection of(stored object, index) tuples. Indexing the zarr array would create a new array supported by a strict subset of the original collection of(stored object, index) tuples. This would also allow indexing to be reversible, i.e. we could concatenate zarr arrays, or build zarr arrays from stored objects on different storage backends.

What is the rationale for that? I think it is quite useful to have a pointer to a file (or even byte range) in a store.

If it's useful to have this, then it should be part of the Store API.StorePath is literally just a store, a string, and a set of convenience methods that use the store and the string. We can get the exact same functionality by putting all of this logic on the store classes themselves, with the benefit of removing a lot of unnecessary code.

Is that the same as array "views"? I would be a fan of that

Yeah, we could think of it like "views" but I think the more basic analogy is with the semantics of slicing generic collections. When you slice into a tuple, you get another tuple, not a numpy array. Zarr should follow the same principle. In concrete terms this would require modelling a zarr array as supported by a collection of(stored object, index) tuples. Indexing the zarr array would create a new array supported by a strict subset of the original collection of(stored object, index) tuples. This would also allow indexing to be reversible, i.e. we could concatenate zarr arrays, or build zarr arrays from stored objects on different storage backends.

I thinkt that would be great. It would need careful API design to become usable and not too confusing. For my cases, an iterator that returns read/writable chunk or shard views would suffice.

yes my plan here is to start with low-level stuff likehttps://github.com/d-v-b/zarr-python/blob/0b9916443d555d9e762f5501314383dc828c26bf/src/zarr/core/array.py#L5253-L5286 and start working that into our indexing routines.