Replies: 1 comment
-
|
see #4119 for a PR that implements this on the zarr-metadata side of things. the idea is that zarr-python would phase out its own |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
proposal
I'm interested in improving the way zarr-python models zarr metadata documents. I think we should aim for metadata documents to be simple python classes that do little more than:
"bytes"and{"name": " "bytes"}and{"name": "bytes", "configuration": {}}to the same object.Then, the job of relating metadata to runtime functionality (like codecs) is the job of a metadata consumer (e.g., the array).
For example, instead of today's
codecs: tuple[CodecClassesThatEncodeStuff, ...], we would havecodecs: tuple[GenericZarrMetadataClass, ...].This buys us a few things:
This would be a breaking change to the
.metadataattribute of the array / async array classes. We would need to create a smooth path for consumers who currently use our existing metadata classes.API outline
I'm thinking something like this (code copy + pasted from another zarr project i'm working on):
Beta Was this translation helpful? Give feedback.
All reactions