Rename StorePath to PathStore?

[dstansby]

All the other stores are named *Store, but StorePath breaks this convention. It might be nice to add a PathStore class, and then eventually deprecate and remove StorePath?

[d-v-b]

StorePath is not a store, it wraps a store and a path.

[d-v-b]

but I agree more broadly that StorePath is a confusing entity. My preferred change would be to implement all of its behavior on store instances themselves, and then have no need for a separate StorePath class.

[dstansby]

Ah, so is it really an abstract base class (or intended to be?)

[d-v-b]

no, StorePath is a regular class that gets instantiated, and it has methods that get used. It compensates for the fact that our Store API only formally supports absolute paths, but for a lot of Zarr IO, paths relative to some other path (e.g., the path to a group) are more convenient.

[jhamman]

@dstansby - okay if we close this as "not planned"?

[dstansby]

I think we should leave it open, but instead of changing the name split up the API doc at https://zarr.readthedocs.io/en/stable/api/zarr/storage/index.html#classes so all the stores are listed together, and StorePath (and antyhgin else that isn't a store) is listed separately.

[d-v-b]

I don't think we need to add complexity to the API docs here. It's simplest if the docs page for the storage module documents all the public stuff in that module. If people think StorePath is a store, they can very quickly find out that it is not, by reading the documentation for that class.

[dstansby]

yeah, that's fair - I've suggested an alternative at #2976 to make the docstrings consistent, which I think would improve things.