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.