-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
closes #75 |
I just pushed a commit that generates a bunch of zarr data types to use in testing |
I fixed the V3 array serialization bugs by allowing the |
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. |
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 |
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.
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
"ignore:The data type:FutureWarning", | ||
"ignore:The codec:UserWarning" |
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.
It would be worth expanding the messages here a bit to give a bit more context on the warnings being ignored.
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.
done in 211fd4c
… into fill-value-fix
I think we can release as soon as this is in |
Could we make sure |
definitely! |
I'd like to merge this today @dstansby any objections? |
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 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 |
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.
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.
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 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, |
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.
This is a breaking change - so it's not forgotton, can you add a changelog entry for it in this PR.
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 don't have a changelog, but I will ensure that this change is noted when we generate release notes in the github release
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 👍 |
thanks @dstansby! |
...instead of
array.fill_value
.