Make constructing v3 ArraySpecs easier

[dstansby]

It's possible to construct a v2 ArraySpec with quite a short call:

ArraySpec(shape=(50, 50), chunks=(32, 32), dtype=np.uint16),

To create the same ArraySpec in v3 requires a much longer call:

ArraySpec(
        shape=(50, 50),
        data_type=np.uint16,
        chunk_grid=NamedConfig(
            name="regular",
            configuration={"chunk_shape": [32, 32]},
        ),
        chunk_key_encoding=NamedConfig(
            name="default", configuration={"separator": "/"}
        ),
        fill_value=0,
        codecs=[NamedConfig(name="bytes")],
    ),

It would be nice to shorten this call somehow. Options could include giving some of the parameters default, or providing some helper function to make constructing ArraySpecs easier.

My suggestions would be:

• Add a regular_chunk_config(shape: tuple[int, ...]) -> NamedConfig helper function
• Make codecs default to [NamedConfig(name="bytes")]
• Possibly make chunk_key_encoding default to the config for "/"

[d-v-b]

totally agree that it's too verbose. fields like chunk_grid and codecs have to be validated against shape and data_type, respectively, so defaults are a little tricky there.

One solution could be to define partial types, that basically have "holes" (configuration.chunk_shape and configuration.endian) which must be filled as part of input validation. This would give us the ability to define a default chunk grid that has everything specified except the chunk shape. defining the chunk shape entails creating a valid chunk grid from the partial one + an externally defined shape (e.g., the shape the user specified). Not sure how this would work, but IMO it's a lot nicer than making chunk_shape optional when it's actually not.

[dstansby]

For chunk grid, I don't think it makes sense to specify a default there, but it could be easier to construct the config (#106).

For data types/codecs, don't all data types work with a single bytes codec?

[d-v-b]

the endian parameter of the bytes codec has to be set if the data type of the array fed to the bytes codec uses multiple bytes per scalar. We could be cheeky and specify the endian parameter for every data type no matter what -- the spec only says that it's required for multi-byte data types, and doesn't say it's disallowed for single-byte data types. Would be good to see how implementations handle this.

[dstansby]

It seems like there's scope to include sensible defaults then, like we currently do for parameters that are not passed to from_array(). Would it be better if defaults were included directly in the ArraySpec parameters, or whether it's best to define a new function or method that looks very similar to from_array() but instead of taking array at the top takes shape and dtype arguments?

My guess is a new function/method would be better, to make sure the ArraySpec class remains a close reflection of the specification.

[d-v-b]

there's a school of thought that argues for basically never overriding __init__, and defining class methods liberally to construct class instances from inputs with various types. I think we could use that approach here, e.g. with a ArraySpec.build or ArraySpec.create method that can take user-friendly parameters without muddying the clean type annotations of the class itself.