Skip to content

use the JSON form of the fill value #77

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

Merged
merged 35 commits into from
Jul 28, 2025
Merged

Conversation

d-v-b
Copy link
Collaborator

@d-v-b d-v-b commented Jul 16, 2025

...instead of array.fill_value.

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 16, 2025

closes #75

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 16, 2025

I just pushed a commit that generates a bunch of zarr data types to use in testing from_zarr. I think it will reveal some interesting failures related to our fill_value annotation

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 16, 2025

I fixed the V3 array serialization bugs by allowing the FIllValue field to have type str. Now I'm porting the same v3 tests over to v2, and finding more fill value bugs to fix :)

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 16, 2025

v2 fill value bugs were extensive, and should now be fixed. Specifically, we were not handling string fill values, and we were also not handling the zarr v2 identifier for a structured dtype properly.

@d-v-b d-v-b marked this pull request as ready for review July 16, 2025 19:57
@d-v-b d-v-b requested a review from dstansby July 16, 2025 19:57
@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 16, 2025

this PR expands the set of properly supported data types. it unlocks support for complex floats in zarr v2, fixed-length unicode strings in v2 and v3, raw bytes in v2 and v3, null terminated bytes in v2 and v3, etc

@d-v-b d-v-b requested review from dstansby and removed request for dstansby July 17, 2025 13:27
Copy link
Collaborator

@dstansby dstansby left a comment

Choose a reason for hiding this comment

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

Looks good to me. My comments are mainly about improving comments to leave a bit more internal documentation about what's going on for future developers looking at the code.

pyproject.toml Outdated
Comment on lines 186 to 187
"ignore:The data type:FutureWarning",
"ignore:The codec:UserWarning"
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be worth expanding the messages here a bit to give a bit more context on the warnings being ignored.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done in 211fd4c

@d-v-b d-v-b requested a review from dstansby July 24, 2025 17:12
@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 24, 2025

I think we can release as soon as this is in

@dstansby
Copy link
Collaborator

Could we make sure ome-zarr-models works fine first before we release, as at least one external check to pick up errors? I'm already testing at ome-zarr-models/ome-zarr-models-py#209, and it looks like it will be fine, but I think it's worth a cross check to catch any easy-to-find bugs before doing a full release.

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 25, 2025

Could we make sure ome-zarr-models works fine first before we release, as at least one external check to pick up errors? I'm already testing at ome-zarr-models/ome-zarr-models-py#209, and it looks like it will be fine, but I think it's worth a cross check to catch any easy-to-find bugs before doing a full release.

definitely!

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 28, 2025

I'd like to merge this today @dstansby any objections?

Copy link
Collaborator

@dstansby dstansby left a comment

Choose a reason for hiding this comment

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

I have some pending review comments that I'll submit - it generally looks good, but my main worry is importing private API. This has bitten me big time in the past, and I think it should be avoided at all costs, especially since we have the power to make it public somewhere in zarr-python.


if TYPE_CHECKING:
from zarr.abc.store import Store
import zarr
from zarr.storage._common import StoreLike
Copy link
Collaborator

Choose a reason for hiding this comment

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

Big 👎 for importing private API. Is there somewhere else this can be imported from? If not, this should be made public over in zarr-python first.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I get the sentiment but lets consider a few things here:

  • Adding public API to zarr python is potentially slow.
  • pydantic-zarr is pre-1.0, so there is no stability guarantee. We should feel enabled to move extremely quickly here.
  • We also know when zarr-python will add / remove API, because we are zarr python devs.

Given these conditions, I don't think using private zarr python API should be a blocker for us. We should just use what we need to use, make an issue about it here and in zarr python, and keep developing this package


def to_zarr(
self,
store: Store,
path: str,
*,
overwrite: bool = False,
**kwargs: Any,
config: ArrayConfigParams | None = None,
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a breaking change - so it's not forgotton, can you add a changelog entry for it in this PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we don't have a changelog, but I will ensure that this change is noted when we generate release notes in the github release

@dstansby
Copy link
Collaborator

Thought I'd post my pending comments in case helpful - I probably won't have time to review thoroughly today though, so no objections to going ahead and merging if you're happy 👍

@d-v-b
Copy link
Collaborator Author

d-v-b commented Jul 28, 2025

thanks @dstansby!

@d-v-b d-v-b merged commit 24094d6 into zarr-developers:main Jul 28, 2025
8 checks passed
@d-v-b d-v-b deleted the fill-value-fix branch July 28, 2025 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants