-
-
Notifications
You must be signed in to change notification settings - Fork 290
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
Basic Zarr-python 2.x compatibility changes #2098
Basic Zarr-python 2.x compatibility changes #2098
Conversation
@classmethod | ||
async def create( | ||
async def from_store( |
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.
In 2.x, Group.create
was used to create an array in the Group.
I slightly prefer from_*
for alternative constructors anyway, so maybe this is a strict improvement and not just a compatibility shim?
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 agree that this needs to change in order to avoid confusion.
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 also a fan of from_X
, and from_store
seems good
store: StoreLike | None = None, | ||
*, |
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.
We can vendor and use https://github.com/scikit-learn/scikit-learn/blob/e87b32a81c70abed8f2e97483758eb64df8255e9/sklearn/utils/validation.py#L32 to deprecate positional arguments. At least of xarray, it passed just store
as a positional argument, but deprecating these doesn't feel like too much work.
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 like this suggestion. Should we do it in 2.18.3 or 3.0 though?
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 don't have a strong preference here.
IMO, calendar time is more meaningful than version numbers for giving projects time to adapt to changes. So I'd say deprecate it in 3.0, as long as we don't have a hard stance on requiring keyword only for these APIs in 3.0
src/zarr/core/group.py
Outdated
@@ -122,8 +122,12 @@ class AsyncGroup: | |||
metadata: GroupMetadata | |||
store_path: StorePath | |||
|
|||
@property | |||
def store(self) -> Store: |
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 we deprecate this, and encourage users to do group.store_path.store
?
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.
github is flagging this conversation as outdated, but regardless: I agree that we should just have either group.store
or group.store_path.store
. But I'm not a huge fan of store_path
actually, so I'd actually favor deprecating that, and going back to v2 behavior where arrays / groups have a store
attribute, and the store has a path
attribute. But this is just my personal opinion, built from finding group.store_path.store
a little weird.
src/zarr/core/group.py
Outdated
return self._async_group.store | ||
|
||
@property | ||
def read_only(self) -> bool: |
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.
Same question as store.
Should probably add this to AsyncGroup
too and update this implementation.
@TomAugspurger - this generally looks like a solid set of fixes. Do you have more here or should try to wrap these up? |
f4c82bc
to
784cb28
Compare
tests/v3/test_attributes.py
Outdated
import zarr.store | ||
|
||
|
||
def test_put(): |
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.
in principle we could test this functionality for other stores. but I also think testing the full product of [array / group features * stores]
is excessive. I guess as long as we are confident that we are densely testing the core store APIs across store types, then it's fine to just test something derived from the store APIs on a single store.
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 think that in this case it's probably OK, since the test here is focused on the behavior of Attributes. This happens to require a reference to a Group (which requires a Store) but hopefully that interface is sufficiently covered by other tests.
I've confirmed that #2157 fixes the CI failure here. |
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.
Thanks @TomAugspurger for pulling these together. Much improved compatibility with v2.
* v3: chore: update pre-commit hooks (zarr-developers#2222) fix: validate v3 dtypes when loading/creating v3 metadata (zarr-developers#2209) fix typo in store integration test (zarr-developers#2223) Basic Zarr-python 2.x compatibility changes (zarr-developers#2098) Make Group.arrays, groups compatible with v2 (zarr-developers#2213) Typing fixes to test_indexing (zarr-developers#2193) Default to RemoteStore for fsspec URIs (zarr-developers#2198) Make MemoryStore serialiazable (zarr-developers#2204) [v3] Implement Group methods for empty, full, ones, and zeros (zarr-developers#2210) implement `store.list_prefix` and `store._set_many` (zarr-developers#2064) Fixed codec for v2 data with no fill value (zarr-developers#2207)
Demonstration of some changes for backwards compatibility being discussed at #2097
TODO: