-
-
Notifications
You must be signed in to change notification settings - Fork 282
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
document storage classes and some developer apis #2279
Conversation
- port normalize_chunks from v2 - add array.store property - default to append in create
also fix failing ci
…nto fix/dask-compat
…nto fix/dask-compat
…nto fix/dask-compat
…nto fix/dask-compat
…nto fix/dask-compat
Would be good to get this up to date with the |
I can rebase this today. |
Okay, @dstansby (and others), this is now ready for a review. |
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've left some comments - one big one, is why so many docstrings deleted? Is it because they're inherited? If so, would be good to include a # docstring inherited
comment where they are inherited so others don't get confused in the future.
Parameters | ||
---------- | ||
mode : AccessModeLiteral | ||
One of 'r', 'r+', 'w', 'w-', 'a'. |
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.
Could we define these as a string somewhere, and then re-use it here and lower down by making the docstring a format string? I worry about lists like this getting out of sync if they're duplicated across docstrings.
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 decided not to do that here because its just this one method. If we have a docstring template tool in the future, I think it would be great to bring that to bear here (and even more so on the Group/Array classes).
@dstansby - ready for another review 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.
I think you can get rid of the custom docstring inheritance code (see my inline comment). Where a docstring is inherited though, please could you leave a # docstring inherited
comment under the signature, to signal to others that come by later that a fresh docstring doesn't need writing.
src/zarr/core/common.py
Outdated
@@ -151,3 +151,33 @@ def parse_order(data: Any) -> Literal["C", "F"]: | |||
if data in ("C", "F"): | |||
return cast(Literal["C", "F"], data) | |||
raise ValueError(f"Expected one of ('C', 'F'), got {data} instead.") | |||
|
|||
|
|||
def _inherit_docstrings(cls: type[Any]) -> type[Any]: |
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.
Docstrings are already automatically inherited, e.g. see Store
and LocalStore
. So I think this isn't needed and can be gotten rid of.
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.
Good for me - might be worth getting someone more familiar with v3 to look over the docstring contents?
closes #2250
TODO: