in writing this PR I noticed that we don't have a create_array function, but we do have create_group. I don't like the asymmetry. We should fix that (by adding a create_array func).

in writing this PR I noticed that we don't have a create_array function, but we do have create_group. I don't like the asymmetry. We should fix that (by adding a create_array func).

I'm wrong, we don't have create_group! But we should! I think we should actually deprecate file-mode semantics across the board in favor of create_x, read_x functions.

This is ready for review. To summarize:

I created 5 new top-level exports:

• read_array
• read_group
• read
• create_array
• create_group

The goal for these functions is to directly support common access patterns without forcing users to worry about the semantics of the mode keyword, and to guard against accessing zarr data with an unintended access mode (e.g., getting mutable access to an array you only want to read).

Some feedback from the community meeting last week:

• One point of contention in this PR was the polymorphic read function, which returns either an array or group, depending on what's in the hierarchy. Personally I think this is invaluable for navigating unknown Zarr hierarchies, but others thought it was unnecessary or confusing. Does anyone else have thoughts?
• Should this PR contain deprecation warnings for functions that are being made less essential by this PR (e.g., open and create)?

from the community meeting:

• create_array should alias create
• we should use these new API functions to compactly express sharding, e.g. create_array(shards=..., chunks=...)