Repository navigation
refactor(zarr-metadata)!: call an extension-point value a declaration - #4592
Merged
d-v-b merged 14 commits intoNov 2, 2026
Merged
Conversation
…int value a declaration Match zarrs and the v3 spec. A name/value pair in a JSON metadata object is now a field everywhere (it was a member), which frees "field" from its old term-of-art meaning: a value at an extension point that a scope resolves, which is now a declaration. The public names for that concept follow: AcceptedField and its siblings become AcceptedDeclaration etc., the ZarrV3*Field aliases become ZarrV3*Declaration, ZarrV3MetadataFieldJSON becomes ZarrV3DeclarationJSON, a reading's fields() becomes declarations(), and unclaimed_fields becomes unclaimed_declarations. Messages that said member now say field. The pickle-rebuild functions keep their names so existing pickles load. Assisted-by: ClaudeCode:claude-opus-5-5
…the rename's changelog Review fixes for the field/declaration rename: an extra field is a declaration written as the field alone, the array models' plain fields are the ones that hold no declaration, must_understand_fields covers extra fields only, and the context guide matches definitions to declarations. The fragment drops four names that were never public and adds spec_fields, the declaration wording of messages, and the renamed JSON Schema $defs keys. Assisted-by: ClaudeCode:claude-opus-5-5
Assisted-by: ClaudeCode:claude-opus-5-5
…ntil it goes upstream towncrier links fragments to upstream zarr-python PRs, and upstream #432 is an unrelated merged PR; this change has only a fork PR so far. Assisted-by: ClaudeCode:claude-opus-5-5
…fork PR CI's changelog check requires an integer PR number, so an orphan fragment cannot land. 432 is the fork PR; renumber it to the upstream PR when this goes upstream. Assisted-by: ClaudeCode:claude-opus-5-5
Resolve the rename against the four zarr-metadata changes main gained: the ZARR_PYTHON_CONTEXT scope and the *_CONTEXT constant names (zarr-developers#4583), the v3 submodule re-exports (zarr-developers#4588), the Hypothesis strategies (zarr-developers#4575) and the docstrings for every public object (zarr-developers#4590). Every conflict was the rename on one side and new upstream text on the other, so each is resolved as the upstream text with the rename applied. The rename is carried into upstream's additions: the new docstrings say "field" for a JSON key and "declaration" for an extension-point value, and the strategies module's `fields` strategy is `declarations`, with `FieldForm` now `DeclarationForm` in its tests. The zarr-developers#4575 changelog fragment uses the new name, since neither name has been released. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…member"
The v3 core spec uses both words for a name/value pair in a metadata
object ("the member chunk_shape", "the fill_value metadata field"), so
only zarrs motivates the choice. Also say "context", not "scope".
Assisted-by: ClaudeCode:claude-fable-5-1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Drop the member-to-field half of the rename. The v3 core spec uses "field", "key" and "member" for a name/value pair without preference, RFC 8259 says "member", and the package already said "member", so only zarrs motivated the change. The field-to-declaration half stays: it removes the collision between the extension-point sense of "field" and the JSON sense in extra_fields, ExtraFieldDefinition and friends. Every line that upstream main writes with "member" is restored by aligning the two trees token by token. spec_fields is spec_members again, member_changes keeps its name, and ZarrV3ConsolidatedMetadata takes member= again. Prose that said "extra member" or "extension member" now says "extra field" and "extension field", after the names. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…borev flagged Four docstrings said "the fields that hold no declaration" for members; the pickle-rebuild comment said the functions keep their _declaration names when they keep their _field names; and two test helpers in the strategies tests still said "fields" for declarations. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ation it reads Last test in the package whose name said "field" for a declaration. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…name in both senses Thirteen test names changed in both the member and the declaration sense at once, so the token alignment that restored "member" skipped them; they take their upstream spelling with only the declaration half applied. Seven docstrings get the same treatment, and the two envelope docstrings that said "an extra field" for an undeclared envelope member now say "an extra envelope member", so "extra field" keeps one meaning. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Last module docstring with "field" in the name/value-pair sense. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
github-actions
Bot
added
needs release notes
Documentation build overview
14 files changed ·
|
…tream PR 4592 Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
d-v-b
marked this pull request as ready for review
November 2, 2026 12:31
d-v-b
added a commit
to d-v-b/zarr-python
that referenced
this pull request
Nov 2, 2026
This branch was squash-merged upstream as zarr-developers#4575 (4a72dd4), whose tree matches this branch's head. Each conflict is main's later change to the same files (zarr-developers#4583, zarr-developers#4588, zarr-developers#4590, zarr-developers#4592), so every file takes main's side, and the branch now matches main. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
d-v-b
added a commit
to d-v-b/zarr-python
that referenced
this pull request
Nov 2, 2026
Main already holds this branch as zarr-developers#4583 (bc177b3, whose tree is this branch's tip), followed by later work such as the declaration rename in zarr-developers#4592. Every conflict therefore resolves to main's side, and the merged tree is main's. Assisted-by: ClaudeCode:claude-opus-5-5
d-v-b
added a commit
to d-v-b/zarr-python
that referenced
this pull request
Nov 2, 2026
…adata-nested-strategies The base now matches main, which carries zarr-developers#4575 and main's later zarr-metadata changes. zarr-developers#4592 renames an extension-point value to a declaration: `fields` is `declarations`, `data_type_fields` is `data_type_declarations`, `AcceptedField` and its siblings are `*Declaration`, and the contexts are `CORE_CONTEXT`, `CORE_AND_EXTENSIONS_CONTEXT` and `ZARR_PYTHON_CONTEXT`; this branch's code and prose follow, where struct fields keep their name. zarr-developers#4583's strategies for zarr-python's data types and the vlen codecs take `Strategies` last, as every record function here does, so strings and variable-length bytes now get pipelines too. The struct test derives which data types vary in size from their storage, and the tests read in `ZARR_PYTHON_CONTEXT`, which holds every definition the strategies draw. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
d-v-b
added a commit
to d-v-b/zarr-python
that referenced
this pull request
Nov 4, 2026
The base branch added private base64 helpers in `_byte.py`. Define the public `base64_fill_value_rules` there, on top of `base64_problems`, instead of in `_numpy.py`, and take the base's versions of `null_terminated_bytes`, `_numpy.py` and the v2 rules. Re-export the rule from `zarr_metadata.v3.data_type`, as zarr-developers#4588 requires of every submodule name, and say "nested declarations" in the docs example, as zarr-developers#4592 does. Assisted-by: ClaudeCode:claude-opus-5-5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
zarr-metadataused the term "field" in two ambiguous senses.In one sense a "field" is an extra member on
zarr.json, e.g. inmust_understand_fields. This follows the spec's own terminology, which broadly uses the terms "key" , "field", and "member" interchangeably to denote the same concept.In another sense, a "field" is a value found at an extension point (a value which may or may not match a known definition), and the spec doesn't really have an name for this.
To keep confusion low, this PR renames these latter "fields" to "declarations".
I will be self-merging this when tests pass. it only affects
zarr-metadata.Author attestation
TODO
docs/user-guide/*.mdchanges/