-
-
Notifications
You must be signed in to change notification settings - Fork 373
refactor metadata into metadata.v2 and metadata.v3 modules
#2059
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
refactor metadata into v2 and v3 modules remove version signifiers from function names fix tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this file also get an __all__?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to this, but I think it would only affect cases where people did from zarr.metadata.v2 import *; from zarr.metadata.v2 import foo would still work whether or not foo is in __all__.
jhamman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice cleanup @d-v-b.
|
|
||
| @property | ||
| def byte_count(self) -> int: | ||
| data_type_byte_counts = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this wasn't introduced here but we should pull all of these dicts into module level variables. No need to recreate them every time we use the datatype.
src/zarr/array.py
Outdated
| @dataclass(frozen=True) | ||
| class AsyncArray: | ||
| metadata: ArrayMetadata | ||
| metadata: ArrayV3Metadata | ArrayV2Metadata |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I slightly favor reverting this change as a way to future proof this a bit.
…nto move-metadata
|
this was addressed by #2163 |
In
main, we handle v2 and v3 metadata differences by having functions with names likefunction_purpose_v2andfunction_purpose_v3. I think it would be more clear to collect all the v2- and v3-specific routines into separate modules.This PR creates new
metadata.v2andmetadata.v3modules for the metadata classes, as well as ametadata.commonmodule, for some routines that have identical v2 and v3 semantics. Functions that previously signified v2-ness or v3-ness in their name now signify it from their location. In this PR The only exports fromzarr.metadataareArrayV2MetadataandArrayV3Metadata.I made a few other related changes:
in
main, we annotate themetadataattribute ofAsyncArraywith the abstract array metadata base class. I changed these annotations toArrayV2Metadata | ArrayV3Metadata, which should be much more useful. In a later effort we could consider makingAsyncArraygeneric over the type of array metadata to give even more information to the type system.In
mainv2 metadata creation relies on an import fromzarr.v2. This will not be valid after v2 is gone, so I ported thev2.normalize_fill_valueroutine intozarr.metadata.v2.parse_fill_value, and made some minor internal changes to the exceptions in that routine.TODO: