diff --git a/docs/contributing.md b/docs/contributing.md index c330504536..e4f341a8b3 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -131,7 +131,7 @@ The hooks can be installed locally by running: prek install ``` -This would run the checks every time a commit is created locally. The checks will by default only run on the files modified by a commit, but the checks can be triggered for all the files by running: +This will run the checks every time a commit is created locally. The checks will by default only run on the files modified by a commit, but the checks can be triggered for all the files by running: ```bash prek run --all-files @@ -249,13 +249,13 @@ Pull requests submitted by an external contributor should be reviewed and approv Pull requests should not be merged until all CI checks have passed (GitHub Actions, Codecov) against code that has had the latest main merged in. -Before merging the milestone must be set either to decide whether a PR will be in the next patch, minor, or major release. The next section explains which types of changes go in each release. +Before merging, the milestone must be set to decide whether a PR will be in the next patch, minor, or major release. The next section explains which types of changes go in each release. ## Compatibility and versioning policies ### Versioning -Versions of this library are identified by a triplet of integers with the form `..`, for example `3.0.4`. A release of `zarr-python` is associated with a new version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the `major` component of the version identifier, the `minor` and `patch` components is reset to 0. When incrementing the minor component, the patch component is reset to 0. +Versions of this library are identified by a triplet of integers with the form `..`, for example `3.0.4`. A release of `zarr-python` is associated with a new version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the `major` component of the version identifier, the `minor` and `patch` components are reset to 0. When incrementing the minor component, the patch component is reset to 0. Releases are classified by the library changes contained in that release. This classification determines which component of the version identifier is incremented on release. @@ -263,7 +263,7 @@ Releases are classified by the library changes contained in that release. This c Users and downstream projects should carefully consider the impact of a major release before adopting it. In advance of a major release, developers should communicate the scope of the upcoming changes, and help users prepare for them. -* **minor** releases (for example, `3.0.0` -> `3.1.0`) are for changes that do not require significant effort from most users or downstream downstream projects to respond to. API changes are possible in minor releases if the burden on users imposed by those changes is sufficiently small. +* **minor** releases (for example, `3.0.0` -> `3.1.0`) are for changes that do not require significant effort from most users or downstream projects to respond to. API changes are possible in minor releases if the burden on users imposed by those changes is sufficiently small. For example, a recently released API may need fixes or refinements that are breaking, but low impact due to the recency of the feature. Such API changes are permitted in a minor release. @@ -271,11 +271,11 @@ Releases are classified by the library changes contained in that release. This c * **patch** releases (for example, `3.1.0` -> `3.1.1`) are for changes that contain no breaking or behaviour changes for downstream projects or users. Examples of changes suitable for a patch release are bugfixes and documentation improvements. - Users should always feel safe upgrading to a the latest patch release. + Users should always feel safe upgrading to the latest patch release. Note that this versioning scheme is not consistent with [Semantic Versioning](https://semver.org/). Contrary to SemVer, the Zarr library may release breaking changes in `minor` releases, or even `patch` releases under exceptional circumstances. But we should strive to avoid doing so. -A better model for our versioning scheme is [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer". The guiding principle off EffVer is to categorize releases based on the *expected effort required to upgrade to that release*. +A better model for our versioning scheme is [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer". The guiding principle of EffVer is to categorize releases based on the *expected effort required to upgrade to that release*. Zarr developers should make changes as smooth as possible for users. This means making backwards-compatible changes wherever possible. When a backwards-incompatible change is necessary, users should be notified well in advance, e.g. via informative deprecation warnings. @@ -288,12 +288,12 @@ If an existing Zarr format version changes, or a new version of the Zarr format ## Release procedure Open an issue on GitHub announcing the release using the release checklist template: -[https://github.com/zarr-developers/zarr-python/issues/new?template=release-checklist.md](https://github.com/zarr-developers/zarr-python/issues/new?template=release-checklist.md>). The release checklist includes all steps necessary for the release. +[https://github.com/zarr-developers/zarr-python/issues/new?template=release-checklist.md](https://github.com/zarr-developers/zarr-python/issues/new?template=release-checklist.md). The release checklist includes all steps necessary for the release. ## Benchmarks Zarr uses [pytest-benchmark](https://pytest-benchmark.readthedocs.io/en/latest/) for running -performance benchmarks as part of our test suite. The benchmarks can be are found in `tests/benchmarks`. +performance benchmarks as part of our test suite. The benchmarks are found in `tests/benchmarks`. By default pytest is configured to run these benchmarks as plain tests (i.e., no benchmarking). To run a benchmark with timing measurements, use the `--benchmark-enable` when invoking `pytest`. diff --git a/docs/quick-start.md b/docs/quick-start.md index 42ac95d169..bb7a556b96 100644 --- a/docs/quick-start.md +++ b/docs/quick-start.md @@ -1,4 +1,4 @@ -This section will help you get up and running with +This section will help you get up and running with the Zarr library in Python to efficiently manage and analyze multi-dimensional arrays. ### Creating an Array @@ -92,7 +92,7 @@ spam[:] = np.arange(10) print(root.tree()) ``` -This creates a group with two datasets: `foo` and `bar`. +This creates a group hierarchy with a group (`foo`) and two arrays (`bar` and `spam`). #### Batch Hierarchy Creation diff --git a/docs/user-guide/arrays.md b/docs/user-guide/arrays.md index f63f5bc6b2..cd6a93cac9 100644 --- a/docs/user-guide/arrays.md +++ b/docs/user-guide/arrays.md @@ -72,7 +72,7 @@ print(z[:, 0]) print(z[:]) ``` -Read more about NumPy-style indexing can be found in the +More information about NumPy-style indexing can be found in the [NumPy documentation](https://numpy.org/doc/stable/user/basics.indexing.html). ## Persistent arrays @@ -297,7 +297,7 @@ array without loading the entire array into memory. Note that although this functionality is similar to some of the advanced indexing capabilities available on NumPy arrays and on h5py datasets, **the Zarr API for advanced indexing is different from both NumPy and h5py**, so please -read this section carefully. For a complete description of the indexing API, +read this section carefully. For a complete description of the indexing API, see the documentation for the [`zarr.Array`][] class. ### Indexing with coordinate arrays diff --git a/docs/user-guide/extending.md b/docs/user-guide/extending.md index d857fa3356..39444135df 100644 --- a/docs/user-guide/extending.md +++ b/docs/user-guide/extending.md @@ -29,7 +29,7 @@ of the array data. Examples include compression codecs, such as Custom codecs for Zarr are implemented by subclassing the relevant base class, see [`zarr.abc.codec.ArrayArrayCodec`][], [`zarr.abc.codec.ArrayBytesCodec`][] and -[`zarr.abc.codec.BytesBytesCodec`][]. Most custom codecs should implemented the +[`zarr.abc.codec.BytesBytesCodec`][]. Most custom codecs should implement the `_encode_single` and `_decode_single` methods. These methods operate on single chunks of the array data. Alternatively, custom codecs can implement the `encode` and `decode` methods, which operate on batches of chunks, in case the codec is intended to implement diff --git a/docs/user-guide/groups.md b/docs/user-guide/groups.md index 57201216b6..e093590dfe 100644 --- a/docs/user-guide/groups.md +++ b/docs/user-guide/groups.md @@ -13,7 +13,7 @@ root = zarr.create_group(store=store) print(root) ``` -Groups have a similar API to the Group class from [h5py](https://www.h5py.org/). For example, groups can contain other groups: +Groups have a similar API to the Group class from [h5py](https://www.h5py.org/). For example, groups can contain other groups: ```python exec="true" session="groups" source="above" foo = root.create_group('foo') diff --git a/docs/user-guide/storage.md b/docs/user-guide/storage.md index 82b576b889..e75cd21381 100644 --- a/docs/user-guide/storage.md +++ b/docs/user-guide/storage.md @@ -91,8 +91,8 @@ print(group) ## Explicit Store Creation -In some cases, it may be helpful to create a store instance directly. Zarr-Python offers four -built-in store: [`zarr.storage.LocalStore`][], [`zarr.storage.FsspecStore`][], +In some cases, it may be helpful to create a store instance directly. Zarr-Python offers +built-in stores: [`zarr.storage.LocalStore`][], [`zarr.storage.FsspecStore`][], [`zarr.storage.ZipStore`][], [`zarr.storage.MemoryStore`][], and [`zarr.storage.ObjectStore`][]. ### Local Store diff --git a/docs/user-guide/v3_migration.md b/docs/user-guide/v3_migration.md index 15425de27a..d5a8067a88 100644 --- a/docs/user-guide/v3_migration.md +++ b/docs/user-guide/v3_migration.md @@ -20,7 +20,7 @@ so we can improve this guide. The goals described above necessitated some breaking changes to the API (hence the major version update), but where possible we have maintained backwards compatibility -in the most widely used parts of the API. This in the [`zarr.Array`][] and +in the most widely used parts of the API. This includes the [`zarr.Array`][] and [`zarr.Group`][] classes and the "top-level API" (e.g. [`zarr.open_array`][] and [`zarr.open_group`][]).