Repository navigation
docs(blog): add post on the Zarr Python 3.1.0 data type overhaul - #4573
Merged
Merged
Conversation
Adds Davis Bennett's design post on the extensible data type model introduced in 3.1.0, dated to the 3.1.0 release (2025-07-14). Converted for the mkdocs-material blog: front matter and excerpt marker, blank lines before lists so Python-Markdown renders them, 4-space list continuations, mkdocs footnote syntax, and relative/autoref links in place of the old Sphinx readthedocs URLs. Fixed the moved examples/custom_dtype link, a broken OpenTeams link, and typos. The unfinished "This would allow writers to define" sentence is dropped and the Arrow paragraph now introduces both proposed features. Code samples verified against current main; mkdocs build renders the post with no new warnings. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The doctests job failed in test_no_unvalidated_blocks because the three python fences in the new blog post had no exec/test attribute. Mark them test="true" (each in its own session, since they are standalone scripts) so they run under the docs harness; they already embed their expected output, so build-time exec rendering is not needed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
thanks for this! I will spend some time tomorrow double-checking my old work 🫣 |
Switch the code blocks from test="true" with hand-written output to exec="true" source="above" result="ansi", matching the other blog posts, so the shown output is generated by markdown-exec rather than pasted in docstrings that nothing checks. Blocks are split per print call (sharing a session) to keep each output next to the call that produced it. Also drop the PEP 723 script headers (the zarr==3.1.0 pin would be false once output comes from the docs build), and use pprint.pformat with print because markdown-exec only captures print(), not pprint.pp. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
I opened a PR against your branch with some proposed changes: maxrjones#9 (since it's markdown, I didn't want to do inline suggestions because I worry about breaking whitespace) |
- Say that "|O" was a Zarr-Python 2 convention. The V2 spec defines no "O" type code. - Use one list of the data types that 3.1 added. Drop variable-length bytes, which 3.0 already supported for V3. - Describe native data types as NumPy data types. CuPy has no data type classes of its own. - Add a note that the post was written for 3.1.0 and that the examples run against the current release. - Mark the placeholder metadata block as text, so it is not highlighted as invalid JSON. - Spell the project name "Zarr-Python", as the other blog posts do. - Fix small wording issues. Assisted-by: ClaudeCode:claude-opus-5-5
Member
Author
thanks! p.s. I intentionally didn't add a release note for this, but lmk if you want one. |
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
This PR adds @d-v-b's blog post on the extensible data type model introduced in the 3.1.0 release. It's quite old at this point, but better late than never IMO.
For reviewers
Author attestation
TODO
docs/user-guide/*.mdchanges/