Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Basic Zarr-python 2.x compatibility changes#2098

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@TomAugspurger
Copy link
Contributor

Demonstration of some changes for backwards compatibility being discussed at#2097

TODO:

  • Add unit tests and/or doctests in docstrings
  • Add docstrings and API docs for any new/modified user-facing classes and functions
  • New/modified features documented in docs/tutorial.rst
  • Changes documented in docs/release.rst
  • GitHub Actions have all passed
  • Test coverage is 100% (Codecov passes)


@classmethod
asyncdefcreate(
asyncdeffrom_store(
Copy link
ContributorAuthor

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 preferfrom_* for alternative constructors anyway, so maybe this is a strict improvement and not just a compatibility shim?

Copy link
Member

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.

Copy link
Contributor

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 offrom_X, andfrom_store seems good

defopen(
*,
store:StoreLike|None=None,
*,
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We can vendor and usehttps://github.com/scikit-learn/scikit-learn/blob/e87b32a81c70abed8f2e97483758eb64df8255e9/sklearn/utils/validation.py#L32 to deprecate positional arguments. At least of xarray, it passed juststore as a positional argument, but deprecating these doesn't feel like too much work.

Copy link
Member

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?

Copy link
ContributorAuthor

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

d-v-b reacted with thumbs up emoji
store_path:StorePath

@property
defstore(self)->Store:
Copy link
ContributorAuthor

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 dogroup.store_path.store?

Copy link
Contributor

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 eithergroup.store orgroup.store_path.store. But I'm not a huge fan ofstore_path actually, so I'd actually favor deprecatingthat, and going back to v2 behavior where arrays / groups have astore attribute, and the store has apath attribute. But this is just my personal opinion, built from findinggroup.store_path.store a little weird.

returnself._async_group.store

@property
defread_only(self)->bool:
Copy link
ContributorAuthor

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 toAsyncGroup too and update this implementation.

@jhamman
Copy link
Member

@TomAugspurger - this generally looks like a solid set of fixes. Do you have more here or should try to wrap these up?

@TomAugspurgerTomAugspurger marked this pull request as ready for reviewAugust 28, 2024 19:24
@TomAugspurgerTomAugspurger changed the title[WIP]: Draft of zarr-python 2.x compatibility changesBasic Zarr-python 2.x compatibility changesSep 3, 2024
importzarr.store


deftest_put():
Copy link
Contributor

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.

Copy link
ContributorAuthor

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.

@jhammanjhamman added the V3 labelSep 13, 2024
@TomAugspurger
Copy link
ContributorAuthor

I've confirmed that#2157 fixes the CI failure here.

Copy link
Member

@jhammanjhamman left a 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.

@jhammanjhamman merged commit6900754 intozarr-developers:v3Sep 20, 2024
24 checks passed
@TomAugspurgerTomAugspurger deleted the user/tom/fix/v2-compat branchSeptember 20, 2024 15:02
dcherian added a commit to dcherian/zarr-python that referenced this pull requestSep 24, 2024
* 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)
@jhammanjhamman added this to the3.0.0.beta milestoneOct 17, 2024
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@d-v-bd-v-bd-v-b left review comments

@jhammanjhammanjhamman approved these changes

Assignees

No one assigned

Labels

None yet

Projects

Status: Done

Milestone

3.0.0.beta

Development

Successfully merging this pull request may close these issues.

3 participants

@TomAugspurger@jhamman@d-v-b

[8]ページ先頭

©2009-2025 Movatter.jp