Normalize paths when creating StorePath

[d-v-b]

In main we don't normalize paths when constructing an instance of StorePath, which means it's possible to create groups with names like a//b. This PR fixes this behavior by ensuring that the path attribute of StorePath is normalized with normalize_path in StorePath.__init__.

There is potentially a problem here if different store classes have different rules about path names. This argues against the existence of a separate StorePath class, and in favor of allowing Store instances to manage their current path.

[dcherian]

There is potentially a problem here if different store classes have different rules about path names.

The spec controls the characters that can be used, and the "separator" is configurable, so I'm finding it hard to see what other axis of flexbility exists.

zarr-python/src/zarr/testing/strategies.py

Lines 79 to 89 in e8bfb64

	# From https://zarr-specs.readthedocs.io/en/latest/v3/core/v3.0.html#node-names
	# 1. must not be the empty string ("")
	# 2. must not include the character "/"
	# 3. must not be a string composed only of period characters, e.g. "." or ".."
	# 4. must not start with the reserved prefix "__"
	zarr_key_chars = st.sampled_from(
	".-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"
	)
	node_names = st.text(zarr_key_chars, min_size=1).filter(
	lambda t: t not in (".", "..") and not t.startswith("__")
	)

[d-v-b]

There is potentially a problem here if different store classes have different rules about path names.

The spec controls the characters that can be used, and the "separator" is configurable, so I'm finding it hard to see what other axis of flexbility exists.

zarr-python/src/zarr/testing/strategies.py

Lines 79 to 89 in e8bfb64

	# From https://zarr-specs.readthedocs.io/en/latest/v3/core/v3.0.html#node-names
	# 1. must not be the empty string ("")
	# 2. must not include the character "/"
	# 3. must not be a string composed only of period characters, e.g. "." or ".."
	# 4. must not start with the reserved prefix "__"
	zarr_key_chars = st.sampled_from(
	".-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"
	)
	node_names = st.text(zarr_key_chars, min_size=1).filter(
	lambda t: t not in (".", "..") and not t.startswith("__")
	)

different key-value storage backends can set different rules about what keys are allowed. e.g., s3 and OSX might have different rules about file name length. It's not terrible if we end up parsing paths twice, but if there's a bug in one parsing path or the other, it would be annoying to look in two different classes to find that bug. I guess my broader complaint is that StorePath is a store with 1 extra property. Any logic we add to StorePath is logic that should exist on the store class itself, and this is duplicative. But we can live with it for now.

[aladinor]

I guess by merging this it will close #2830 right @d-v-b?

[d-v-b]

I believe so

[dcherian]

shall we delete line 287 then.

[d-v-b]

64ef489

[TomNicholas]

Can we merge this? I think it's blocking DataTree compatibility.

[d-v-b]

@dcherian could you review this?

[dstansby]

LGTM. Is this fixing a bug? (from the description it seems so?). If so, it should get a changelog entry explaining to users what's fixed. Also I left one minor test suggestion inline.

[dstansby]

I do think the old test here is useful (in addition to the updated test), because it shows explicitly what the values of all the properties are, making it much easier to see what's changed if they change (which they might have done with this PR). So I'd be pro just copy/pasting the old test back here along with the new test?

[d-v-b]

the new test is the same as the old test, but parametrized instead of 2 cases copy + pasted

[d-v-b]

as a rule we should avoid tests that follow the "copy + pasted code blocks with minor modifications" pattern. these are huge source of friction when fixing bugs. that friction should be reduced by using parametrization where we can, as I did here.

[dstansby]

Agree that we shouldn't copy/paste with minor modifications, but I think one test that hard codes the results instead of using other properties is worthwhile to have.