-
-
Notifications
You must be signed in to change notification settings - Fork 329
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
src/zarr/metadata/v2.py
Outdated
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__
.
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.
src/zarr/metadata/v3.py
Outdated
|
||
@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
@@ -92,14 +92,14 @@ def create_codec_pipeline(metadata: ArrayV2Metadata | ArrayV3Metadata) -> CodecP | |||
|
|||
@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.
this was addressed by #2163 |
In
main
, we handle v2 and v3 metadata differences by having functions with names likefunction_purpose_v2
andfunction_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.v2
andmetadata.v3
modules for the metadata classes, as well as ametadata.common
module, 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.metadata
areArrayV2Metadata
andArrayV3Metadata
.I made a few other related changes:
in
main
, we annotate themetadata
attribute ofAsyncArray
with 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 makingAsyncArray
generic over the type of array metadata to give even more information to the type system.In
main
v2 metadata creation relies on an import fromzarr.v2
. This will not be valid after v2 is gone, so I ported thev2.normalize_fill_value
routine intozarr.metadata.v2.parse_fill_value
, and made some minor internal changes to the exceptions in that routine.TODO: