From 97adeecb8f6568ce39756c0419d65dac95a88a50 Mon Sep 17 00:00:00 2001
From: Max Jones <14077947+maxrjones@users.noreply.github.com>
Date: Wed, 28 Oct 2026 19:16:58 +0000
Subject: [PATCH 1/4] docs(blog): add post on the Zarr Python 3.1.0 data type
 overhaul

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>
---
 docs/blog/posts/3.1.0-data-types.md | 341 ++++++++++++++++++++++++++++
 1 file changed, 341 insertions(+)
 create mode 100644 docs/blog/posts/3.1.0-data-types.md

diff --git a/docs/blog/posts/3.1.0-data-types.md b/docs/blog/posts/3.1.0-data-types.md
new file mode 100644
index 0000000000..a5e51d3f28
--- /dev/null
+++ b/docs/blog/posts/3.1.0-data-types.md
@@ -0,0 +1,341 @@
+---
+date: 2025-07-14
+authors:
+  - d-v-b
+categories:
+  - Release
+---
+
+# New data types in Zarr Python 3.1.0
+
+The [3.1.0 release](../../release-notes.md#310-2025-07-14) of Zarr Python overhauls our internal model of array data types. This is exciting for two reasons:
+
+First, we added Zarr V3 support for a lot of NumPy data types, including datetimes, timedeltas, Unicode strings, null-terminated bytes, raw bytes, and structured data types. This unblocks Zarr V2 users who couldn't migrate to Zarr V3 until these data types were added.
+
+Second, Zarr Python data types are now *extensible*. If you have a NumPy-compatible data type class that Zarr Python doesn't already support, like [`bfloat16`](https://github.com/jax-ml/ml_dtypes?tab=readme-ov-file#bfloat16), you can define a Zarr data type that wraps that data type! Here's a [self-contained, executable example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py) that walks through the entire process.
+
+<!-- more -->
+
+There's more to the data type extensibility story than just implementing a new data type in Zarr Python. A widely-used data type should have a *published standard* so different Zarr libraries can all consistently implement that data type.
+
+That's why the Zarr community has created the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project. `zarr-extensions` is a central repository for community-defined data types (and other extensions to the Zarr data model, like codecs and chunk grids). Check out the [specification document](https://github.com/zarr-developers/zarr-extensions/tree/main/data-types/bfloat16) for the `bfloat16` data type for an example.
+
+To dive right in to this new feature, head over to our new [data type documentation page](../../user-guide/data_types.md) and read more about how this new data type system works in Zarr Python.
+
+But perhaps you'd like to know more about the *context* for this new feature. The best way to convey that is to answer the following two questions:
+
+- What is Zarr's "data type model" anyway?
+- How did we make data types extensible in Zarr Python? And why now?
+
+That's what the rest of this post is about.
+
+## Zarr's data type model
+
+This section will explain how data types were declared in Zarr V2, why we did it that way, why that turned out to be problematic, and how we improved things in Zarr V3.
+
+### NumPy x Zarr
+
+The Zarr format and the Zarr Python library are heavily influenced by NumPy's approach to arrays and data types. NumPy's influence is even written explicitly into the Zarr V2 specification:
+
+> Simple data types are encoded within the array metadata as a string,
+> following the [NumPy array protocol type string (typestr) format](https://numpy.org/doc/stable/reference/arrays.interface.html#the-array-interface-protocol).
+>
+> -- [The Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding)
+
+On the implementation side, Zarr Python uses NumPy internally, and we expose Zarr array data to users in the form of NumPy arrays or arrays that follow the NumPy API (like [cupy arrays](https://docs.cupy.dev/en/stable/reference/ndarray.html)).
+
+In some areas Zarr and NumPy fit together very well. They both describe arrays, after all. But the two projects have *very* different scopes: typical NumPy arrays live in memory of a single Python program. Zarr arrays are often persisted to external storage and accessed by many different programs, in many different programming languages, over many years.
+
+In my opinion, these fundamentally divergent design goals limit how much Zarr can borrow directly from NumPy.
+
+One of the big changes in the Zarr V3 spec was dropping NumPy compatibility in its data type definition. To inform some of the reasons for this choice, the next section will show just how tightly coupled Zarr V2 was to NumPy, and how this was ultimately problematic.
+
+### NumPy's influence on Zarr V2
+
+Every Zarr V2 array is defined by a JSON metadata document. This document declares the information necessary to read from the array, including the array's shape, data type, chunks, etc. All of that metadata must be JSON serializable.
+
+For data types in particular, the Zarr V2 format defined a JSON serialization scheme that simply copied a particular[^1] string representation of NumPy data types. This is demonstrated in the following script:
+
+```python
+# /// script
+# requires-python = ">=3.11"
+# dependencies = ["zarr>=3.1"]
+# ///
+
+import numpy as np
+import zarr
+import pprint
+
+
+dtype_str='<c16'
+
+# make a numpy array
+np_data = np.array([0 + 1j, 1 + 1j, 2 + 3j], dtype=dtype_str)
+
+# make a zarr v2 array from our numpy array
+z_data = zarr.from_array({}, data=np_data, zarr_format=2)
+
+meta_dict = z_data.metadata.to_dict()
+
+# check out the metadata document
+pprint.pp(meta_dict)
+"""
+{
+    'shape': (3,),
+    'chunks': (3,),
+    'dtype': '<c16',
+    'fill_value': (0.0, 0.0),
+    'order': 'C',
+    'filters': None,
+    'dimension_separator': '.',
+    'compressor': {'id': 'zstd', 'level': 0},
+    'attributes': {},
+    'zarr_format': 2
+}
+"""
+# The numpy .str attribute is the same
+# as the dtype field in Zarr V2 metadata
+print(np_data.dtype.str == meta_dict["dtype"])
+"""
+True
+"""
+```
+
+There are some advantages to copying NumPy data type strings:
+
+- Strings are JSON serializable. We can easily store these NumPy strings in Zarr metadata documents without defining a special JSON serialization procedure.
+- Using NumPy strings gives Zarr easy NumPy compatibility -- we can just call `np.dtype` on the string to get the right NumPy data type.
+
+If Zarr only supported integers and floating point numbers, maybe the story could end here. But Zarr V2 supports other data types, namely variable-length data types, (because Zarr V2 users *needed* these data types), and with these data types we see the limits of copying strings from NumPy.
+
+#### Variable-length data types
+
+The biggest problem with using NumPy data type strings in Zarr is that *distinct Zarr data types have the same NumPy string representation*. In other words, there are more Zarr data types than NumPy data types.
+
+Prior to NumPy 2.0 (when Zarr V2 was defined) there was no data type for an array of strings with variable length, like `["a", "bb", "ccc"]`. NumPy supported these arrays with the ["Object" data type](https://numpy.org/doc/stable/reference/arrays.scalars.html#numpy.object_), which supports arrays of arbitrary Python objects (including strings) by storing a buffer of references.
+
+The "Object" data type has a string identifier of `"|O"`, and "Object" data type arrays can contain *any* Python object, including but not limited to variable length strings. So two object arrays with very different contents will have the same data type identifier:
+
+```python
+# /// script
+# requires-python = ">=3.11"
+# dependencies = ["numpy"]
+# ///
+
+import numpy as np
+
+vlen_str = np.array(["a", "bb"], dtype="O")
+vlen_array = np.array([[0], [1,2]], dtype="O")
+
+print(vlen_str.dtype.str)
+"""
+|O
+"""
+print(vlen_array.dtype.str)
+"""
+|O
+"""
+```
+
+The above example is relevant because Zarr Python 2 supported arrays of variable length strings *and* arrays of variable length arrays. According to the [Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding), these two distinct data types are both declared as `"dtype": "|O"` in metadata documents (because they are both the "same" data type from NumPy's POV).
+
+This is clearly a problem. From a Zarr point of view a variable-length array of strings is *very different* from a variable-length array of arrays. Zarr needs to store arrays on disk, and the storage procedure is very different for these two distinct data types.
+
+Zarr Python solved this with a hack: an array of variable-length strings was *operationally* defined as an array with the following configuration in metadata:
+
+- the data type is declared as `"|O"`.
+- the chunk encoding for the array included a special "variable-length UTF8" codec. This could be found either in the `filters` field or the `compressor` field.
+
+And an array of variable-length arrays was operationally defined similarly, although with a *different* special codec (one designed specifically for variable-length arrays).
+
+Clearly it's problematic if the metadata field responsible for declaring the data type for the array (`dtype`) doesn't fully declare the data type for the array in some cases! Zarr Python hacked around this by storing some data-type-specific information in the filters / compressor for an array, but this is far from ideal (and this behavior was never fully specified).
+
+### Zarr Version 3
+
+Coupling Zarr's data type definition to an implementation detail of a particular (albeit, highly significant) Python library like NumPy proved a limiting choice for Zarr V2. Wisely, the authors of the Zarr V3 spec chose not to define array data types by copying a detail of NumPy's API.
+
+Instead, data types in Zarr V3 are declared in one of two ways:
+
+- as a string, like `"int64"`, which declares the signed 64-bit integer data type. Note that unlike NumPy, Zarr V3 data types are generally not defined with a byte order.
+- as a JSON object with the following form:
+
+    ```json
+    {
+     "name": <data type name>,
+     "configuration": {...<data type configuration>}
+    }
+    ```
+
+This brings immediate advantages over the Zarr V2 data type model.
+
+#### Extensible data types
+
+Instead of copying NumPy, the Zarr V3 specification defines a list of core data types that all Zarr implementations ought to support. But we also think people should be able to create new data types, and we don't want to update the core Zarr V3 specification every time that happens.
+
+Instead, the Zarr community maintains the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project, which collects specification documents for community-defined data types. `zarr-extensions` is a lightweight coordination mechanism that ensures people designing their own data types can avoid name collisions with other pre-existing community-defined data types.
+
+We also think writing data type specifications in the open will drive awareness and adoption of new data types across multiple Zarr implementations.
+
+#### Using more of JSON
+
+By ditching the Zarr V2 string-only data type definition, we can use JSON objects to more explicitly model data types that have significant parametrization.
+
+For example, NumPy defines [two data types](https://numpy.org/doc/stable/reference/arrays.datetime.html) for temporal *moments* (`datetime64`) and *intervals* (`timedelta64`). Both of these data types are parametrized by a time unit and a scaling factor. Zarr V2 used the NumPy string representation of these data types, leading to [stringly typed](https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed) data type declarations like `"<M8[10ns]"`, which encodes a little-endian `datetime64` with a scale factor of 10 and a unit of nanoseconds.
+
+In Zarr V3, we use a much more explicit representation to express the same data type:
+
+```json
+{
+    "name": "numpy.datetime64",
+    "configuration": {"scale_factor": 10, "unit": "ns"}
+}
+```
+
+This JSON object is defined in a [published specification](https://github.com/zarr-developers/zarr-extensions/tree/main/data-types/numpy.datetime64) for this data type, which ensures that someone implementing this data type in a different programming language has a clear point of reference. Which brings us to the last point: ensuring interoperability.
+
+#### Ensuring interoperability
+
+Defining Zarr data types in-house is good for Zarr implementations today, but we think it's also the right choice for data consumers in the future.
+
+If we kept NumPy as a dependency for Zarr V3, the Zarr ecosystem would be vulnerable to a scenario in which NumPy changes how they represent data types, which could complicate reading Zarr data written in the past.
+
+That's enough about the spec story. Now we'll shift gears and talk about how we finally embraced the Zarr V3 data type model in the 3.1 release of Zarr Python.
+
+## What's changed in Zarr Python 3.1.0
+
+We shipped [Zarr Python 3.0](https://zarr.dev/blog/zarr-python-3-release/) back in January with support for a fixed set of array data types. To get the 3.0 release out quickly, we made a lot of short-term design choices, like handling data types for Zarr V2 arrays and Zarr V3 arrays in completely separate code paths. We also relied heavily on NumPy data type classes internally.
+
+This was fast to ship, but it proved expensive in terms of technical debt -- separate code paths for V2 and V3 arrays led to code duplication, and worse, we introduced a lot of unnecessary complexity for operations that could, in principle, be represented more simply.
+
+There were other problems -- Zarr Python 3.0 did not ship with support for a few important Zarr V2 / NumPy data types, namely datetimes, timedeltas, and fixed-length UTF-32 strings. People who had used these data types with Zarr Python 2.x could not migrate to Zarr V3 until we added support for these data types.
+
+So while squashing a lot of the urgent post-3.0-release bugs, we started thinking about a coherent, extensible model for data types, since it was clear that we couldn't commit to longer-term maintenance for our initial data type model.
+
+Things got a lot more real in late January when [Nick Byrne](https://github.com/nenb/), an engineer at [OpenTeams](https://openteams.com/), drafted a [concrete proposal](https://github.com/zarr-developers/zarr-python/pull/2750) for a new data type API.
+
+Nick's proposal was hugely influential; when [Earthmover](https://earthmover.io/) contracted me to add fixed-length strings to Zarr Python, I realized that the total cost of adding a new data type to our existing data type API would, over the long term, cost more time than a full re-design. So I started work on a [pull request](https://github.com/zarr-developers/zarr-python/pull/2874) that extended Nick's ideas to as many data types as possible.
+
+Through the 300+ comments on that pull request, and many more comments in the associated [discussion on the Zarr developer chat](https://ossci.zulipchat.com/#narrow/channel/423692-Zarr/topic/extensible.20dtypes), we built an API that's pretty good, or at least it's good enough for now :sweat_smile:.
+
+### ZDType
+
+The basic design revolves around one class per data type. Each Zarr data type class, or `ZDType`, relates two other distinct Python types:
+
+- The *"native" data type*
+
+    This is the in-memory data type Zarr Python will use when returning decoded chunks of a Zarr array to users. Right now all the native data types are NumPy or CuPy data types, but hopefully we support more array backends in the future!
+
+- The *scalar type*
+
+    This is the type of the individual elements inside an array.
+
+    To illustrate how this type is not the same as the "native" data type, consider the variable-length string data type. With older versions of NumPy, the native data type is the NumPy "Object" data type; with newer versions of NumPy, we can use the [Variable-length string data type](https://numpy.org/devdocs/user/basics.strings.html#variable-width-strings). But in either case the scalar type is `str`: a plain Python string.
+
+Each `ZDType` defines the following behaviors:
+
+- Creating an appropriate native data type
+- Reading from an appropriate native data type
+- Creating Zarr V2 and Zarr V3-compatible data type metadata
+- Reading Zarr V2 and Zarr V3-compatible data type metadata
+- Encoding and decoding scalar values from Zarr V2 and Zarr V3 metadata.
+
+    This is necessary because many data types use special JSON serialization schemes for scalar values that are stored in the `"fill_value"` field in array metadata.
+
+- Casting in-memory Python objects to scalar values
+
+We can demonstrate everything with a simple example:
+
+```python
+# /// script
+# requires-python = ">=3.11"
+# dependencies = ["zarr==3.1.0"]
+# ///
+
+import numpy as np
+from zarr.dtype import DateTime64
+
+npd = np.dtype('datetime64[10ns]')
+zd = DateTime64.from_native_dtype(npd)
+
+print(zd)
+"""
+DateTime64(endianness='little', scale_factor=10, unit='ns')
+"""
+
+print(zd.to_native_dtype() == npd)
+"""
+True
+"""
+
+# The "name" key is what we will actually
+# write to Zarr V2 metadata.
+print(zd.to_json(zarr_format=2))
+"""
+{'name': '<M8[10ns]', 'object_codec_id': None}
+"""
+
+print(zd.to_json(zarr_format=3))
+"""
+{'name': 'numpy.datetime64', 'configuration': {'unit': 'ns', 'scale_factor': 10}}
+"""
+
+print(zd.cast_scalar(10))
+"""
+1970-01-01T00:00:00.000000100
+"""
+
+print(zd.from_json_scalar(10, zarr_format=3))
+"""
+1970-01-01T00:00:00.000000100
+"""
+```
+
+Adding a new data type to Zarr Python is now as simple as implementing a new `ZDType` class and registering it. That whole process is demonstrated in [this self-contained example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py).
+
+And that's pretty much it -- each `ZDType` defines an interface between the Zarr V2 / V3 metadata representations on one side, and in-memory python objects on the other. `ZDType` classes can be added at runtime by users, and we can ship more `ZDType` classes with Zarr Python as more community data types are minted.
+
+### New (old) data types
+
+Zarr Python 3.0 shipped without all the data types that Zarr Python 2.x supported. Zarr Python 3.1 adds full support for these data types, across Zarr V2 and V3:
+
+- [Fixed-length raw bytes][zarr.dtype.RawBytes]
+- [Fixed-length null-terminated bytes][zarr.dtype.NullTerminatedBytes]
+- [Variable-length bytes][zarr.dtype.VariableLengthBytes]
+- [Fixed-length UTF-32 strings][zarr.dtype.FixedLengthUTF32]
+- [Datetime64][zarr.dtype.DateTime64]
+- [Timedelta64][zarr.dtype.TimeDelta64]
+- [Structured data types][zarr.dtype.Structured]
+
+For the full list of supported data types, see the [Zarr Python docs](../../user-guide/data_types.md#list-of-data-types).
+
+## What's next
+
+The Zarr V2 data type model incidentally made NumPy a soft dependency for the entire Zarr ecosystem. This proved problematic for a data format implemented in multiple languages, and it ultimately limited our ability to define new data types.
+
+The Zarr V3 spec fixed this with a *de novo* extensible data type model, but Zarr Python didn't fully implement that model until Zarr Python version 3.1. With Zarr Python 3.1 released, and the `zarr-extensions` project up and running, we're very excited to see what the Zarr community does with these long-awaited features.
+
+In the short term, we hope machine learning engineers take full advantage of Zarr for cloud-friendly, scalable array storage.
+
+Longer term, there are some features we could add to the Zarr data type model.
+
+One common user request is a framework for declaring *nullable* data types, i.e. data types that combine a conventional data type with an optional value. This greatly simplifies the expression of arrays with missing data.
+
+Another feature would be a data type model that allowed readers to *partially* support a data type.
+
+For both of these features, the [Apache Arrow data type model](https://arrow.apache.org/docs/format/Columnar.html#data-types) looks very enticing. Arrow supports nullable data types, and defines behaviors for partially-supported data types. What would it take for Zarr to include Arrow buffers as an alternative array backend?
+
+## Who supported this
+
+Several groups of people contributed resources that enabled this work.
+
+The [Zarr spec contributors](https://github.com/zarr-developers/zarr-specs/graphs/contributors) did the foundational work of delivering a Zarr V3 specification that made this work expressible.
+
+The [Zarr Python contributors](https://github.com/zarr-developers/zarr-python/graphs/contributors) built the foundational Zarr implementation in Python, and provided extensive feedback during the development process of the work described in this post.
+
+[OpenTeams](https://openteams.com/) supported Nick Byrne's invaluable work as a PR reviewer.
+
+[Earthmover](https://earthmover.io/) supported my work on the first half of this project, and [Development Seed](https://developmentseed.org/) supported the culmination.
+
+We are immensely grateful to the folks at all of these orgs who made this happen!
+
+[^1]: I say "particular" because NumPy supports multiple string representations of the same data type. NumPy interprets `"|b1"`, `">b1"`, `"<b1"`, `"=b1"`, `"bool"` as declarations of the same boolean data type.

From ca3f1e01c2e97c6b0eca4b8d8e9b1a824a63cf35 Mon Sep 17 00:00:00 2001
From: Max Jones <14077947+maxrjones@users.noreply.github.com>
Date: Wed, 28 Oct 2026 20:26:08 +0000
Subject: [PATCH 2/4] docs(blog): mark 3.1.0 data type post code blocks as
 tested

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>
---
 docs/blog/posts/3.1.0-data-types.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/blog/posts/3.1.0-data-types.md b/docs/blog/posts/3.1.0-data-types.md
index a5e51d3f28..733902eec4 100644
--- a/docs/blog/posts/3.1.0-data-types.md
+++ b/docs/blog/posts/3.1.0-data-types.md
@@ -56,7 +56,7 @@ Every Zarr V2 array is defined by a JSON metadata document. This document declar
 
 For data types in particular, the Zarr V2 format defined a JSON serialization scheme that simply copied a particular[^1] string representation of NumPy data types. This is demonstrated in the following script:
 
-```python
+```python test="true" session="blog-310-v2-dtype"
 # /// script
 # requires-python = ">=3.11"
 # dependencies = ["zarr>=3.1"]
@@ -116,7 +116,7 @@ Prior to NumPy 2.0 (when Zarr V2 was defined) there was no data type for an arra
 
 The "Object" data type has a string identifier of `"|O"`, and "Object" data type arrays can contain *any* Python object, including but not limited to variable length strings. So two object arrays with very different contents will have the same data type identifier:
 
-```python
+```python test="true" session="blog-310-object-dtype"
 # /// script
 # requires-python = ">=3.11"
 # dependencies = ["numpy"]
@@ -245,7 +245,7 @@ Each `ZDType` defines the following behaviors:
 
 We can demonstrate everything with a simple example:
 
-```python
+```python test="true" session="blog-310-dtype-api"
 # /// script
 # requires-python = ">=3.11"
 # dependencies = ["zarr==3.1.0"]

From 5ac5e721ad8781936a9111a0dea9739f9f50ea8d Mon Sep 17 00:00:00 2001
From: Max Jones <14077947+maxrjones@users.noreply.github.com>
Date: Wed, 28 Oct 2026 20:39:08 +0000
Subject: [PATCH 3/4] docs(blog): render 3.1.0 data type post examples at build
 time

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>
---
 docs/blog/posts/3.1.0-data-types.md | 82 +++++++----------------------
 1 file changed, 19 insertions(+), 63 deletions(-)

diff --git a/docs/blog/posts/3.1.0-data-types.md b/docs/blog/posts/3.1.0-data-types.md
index 733902eec4..dffd0ac5ea 100644
--- a/docs/blog/posts/3.1.0-data-types.md
+++ b/docs/blog/posts/3.1.0-data-types.md
@@ -54,20 +54,14 @@ One of the big changes in the Zarr V3 spec was dropping NumPy compatibility in i
 
 Every Zarr V2 array is defined by a JSON metadata document. This document declares the information necessary to read from the array, including the array's shape, data type, chunks, etc. All of that metadata must be JSON serializable.
 
-For data types in particular, the Zarr V2 format defined a JSON serialization scheme that simply copied a particular[^1] string representation of NumPy data types. This is demonstrated in the following script:
-
-```python test="true" session="blog-310-v2-dtype"
-# /// script
-# requires-python = ">=3.11"
-# dependencies = ["zarr>=3.1"]
-# ///
+For data types in particular, the Zarr V2 format defined a JSON serialization scheme that simply copied a particular[^1] string representation of NumPy data types. This is demonstrated in the following example:
 
+```python exec="true" session="blog-310-v2-dtype" source="above" result="ansi"
 import numpy as np
 import zarr
 import pprint
 
-
-dtype_str='<c16'
+dtype_str = '<c16'
 
 # make a numpy array
 np_data = np.array([0 + 1j, 1 + 1j, 2 + 3j], dtype=dtype_str)
@@ -78,27 +72,13 @@ z_data = zarr.from_array({}, data=np_data, zarr_format=2)
 meta_dict = z_data.metadata.to_dict()
 
 # check out the metadata document
-pprint.pp(meta_dict)
-"""
-{
-    'shape': (3,),
-    'chunks': (3,),
-    'dtype': '<c16',
-    'fill_value': (0.0, 0.0),
-    'order': 'C',
-    'filters': None,
-    'dimension_separator': '.',
-    'compressor': {'id': 'zstd', 'level': 0},
-    'attributes': {},
-    'zarr_format': 2
-}
-"""
+print(pprint.pformat(meta_dict, sort_dicts=False))
+```
+
+```python exec="true" session="blog-310-v2-dtype" source="above" result="ansi"
 # The numpy .str attribute is the same
 # as the dtype field in Zarr V2 metadata
 print(np_data.dtype.str == meta_dict["dtype"])
-"""
-True
-"""
 ```
 
 There are some advantages to copying NumPy data type strings:
@@ -116,25 +96,14 @@ Prior to NumPy 2.0 (when Zarr V2 was defined) there was no data type for an arra
 
 The "Object" data type has a string identifier of `"|O"`, and "Object" data type arrays can contain *any* Python object, including but not limited to variable length strings. So two object arrays with very different contents will have the same data type identifier:
 
-```python test="true" session="blog-310-object-dtype"
-# /// script
-# requires-python = ">=3.11"
-# dependencies = ["numpy"]
-# ///
-
+```python exec="true" session="blog-310-object-dtype" source="above" result="ansi"
 import numpy as np
 
 vlen_str = np.array(["a", "bb"], dtype="O")
 vlen_array = np.array([[0], [1,2]], dtype="O")
 
 print(vlen_str.dtype.str)
-"""
-|O
-"""
 print(vlen_array.dtype.str)
-"""
-|O
-"""
 ```
 
 The above example is relevant because Zarr Python 2 supported arrays of variable length strings *and* arrays of variable length arrays. According to the [Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding), these two distinct data types are both declared as `"dtype": "|O"` in metadata documents (because they are both the "same" data type from NumPy's POV).
@@ -245,12 +214,7 @@ Each `ZDType` defines the following behaviors:
 
 We can demonstrate everything with a simple example:
 
-```python test="true" session="blog-310-dtype-api"
-# /// script
-# requires-python = ">=3.11"
-# dependencies = ["zarr==3.1.0"]
-# ///
-
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
 import numpy as np
 from zarr.dtype import DateTime64
 
@@ -258,36 +222,28 @@ npd = np.dtype('datetime64[10ns]')
 zd = DateTime64.from_native_dtype(npd)
 
 print(zd)
-"""
-DateTime64(endianness='little', scale_factor=10, unit='ns')
-"""
+```
 
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
 print(zd.to_native_dtype() == npd)
-"""
-True
-"""
+```
 
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
 # The "name" key is what we will actually
 # write to Zarr V2 metadata.
 print(zd.to_json(zarr_format=2))
-"""
-{'name': '<M8[10ns]', 'object_codec_id': None}
-"""
+```
 
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
 print(zd.to_json(zarr_format=3))
-"""
-{'name': 'numpy.datetime64', 'configuration': {'unit': 'ns', 'scale_factor': 10}}
-"""
+```
 
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
 print(zd.cast_scalar(10))
-"""
-1970-01-01T00:00:00.000000100
-"""
+```
 
+```python exec="true" session="blog-310-dtype-api" source="above" result="ansi"
 print(zd.from_json_scalar(10, zarr_format=3))
-"""
-1970-01-01T00:00:00.000000100
-"""
 ```
 
 Adding a new data type to Zarr Python is now as simple as implementing a new `ZDType` class and registering it. That whole process is demonstrated in [this self-contained example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py).

From cc84304dfb1b5f1a7fc80b082233d9af2b6c959d Mon Sep 17 00:00:00 2001
From: Davis Bennett <davis.v.bennett.git@gmail.com>
Date: Fri, 30 Oct 2026 15:54:21 +0100
Subject: [PATCH 4/4] docs(blog): correct facts and wording in the 3.1.0 data
 type post (#9)

- 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
---
 docs/blog/posts/3.1.0-data-types.md | 72 +++++++++++++++--------------
 1 file changed, 37 insertions(+), 35 deletions(-)

diff --git a/docs/blog/posts/3.1.0-data-types.md b/docs/blog/posts/3.1.0-data-types.md
index dffd0ac5ea..a211ce956e 100644
--- a/docs/blog/posts/3.1.0-data-types.md
+++ b/docs/blog/posts/3.1.0-data-types.md
@@ -6,49 +6,52 @@ categories:
   - Release
 ---
 
-# New data types in Zarr Python 3.1.0
+# New data types in Zarr-Python 3.1.0
 
-The [3.1.0 release](../../release-notes.md#310-2025-07-14) of Zarr Python overhauls our internal model of array data types. This is exciting for two reasons:
+!!! note
+    This post was written for the 3.1.0 release in July 2025. The code examples run against the current release of Zarr-Python.
 
-First, we added Zarr V3 support for a lot of NumPy data types, including datetimes, timedeltas, Unicode strings, null-terminated bytes, raw bytes, and structured data types. This unblocks Zarr V2 users who couldn't migrate to Zarr V3 until these data types were added.
+The [3.1.0 release](../../release-notes.md#310-2025-07-14) of Zarr-Python overhauls our internal model of array data types. This is exciting for two reasons:
 
-Second, Zarr Python data types are now *extensible*. If you have a NumPy-compatible data type class that Zarr Python doesn't already support, like [`bfloat16`](https://github.com/jax-ml/ml_dtypes?tab=readme-ov-file#bfloat16), you can define a Zarr data type that wraps that data type! Here's a [self-contained, executable example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py) that walks through the entire process.
+First, we added Zarr V3 support for a lot of NumPy data types, including datetimes, timedeltas, fixed-length Unicode strings, null-terminated bytes, raw bytes, and structured data types. This unblocks Zarr V2 users who couldn't migrate to Zarr V3 until these data types were added.
+
+Second, Zarr-Python data types are now *extensible*. If you have a NumPy-compatible data type class that Zarr-Python doesn't already support, like [`bfloat16`](https://github.com/jax-ml/ml_dtypes?tab=readme-ov-file#bfloat16), you can define a Zarr data type that wraps that data type! Here's a [self-contained, executable example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py) that walks through the entire process.
 
 <!-- more -->
 
-There's more to the data type extensibility story than just implementing a new data type in Zarr Python. A widely-used data type should have a *published standard* so different Zarr libraries can all consistently implement that data type.
+There's more to the data type extensibility story than just implementing a new data type in Zarr-Python. A widely-used data type should have a *published standard* so different Zarr libraries can all consistently implement that data type.
 
 That's why the Zarr community has created the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project. `zarr-extensions` is a central repository for community-defined data types (and other extensions to the Zarr data model, like codecs and chunk grids). Check out the [specification document](https://github.com/zarr-developers/zarr-extensions/tree/main/data-types/bfloat16) for the `bfloat16` data type for an example.
 
-To dive right in to this new feature, head over to our new [data type documentation page](../../user-guide/data_types.md) and read more about how this new data type system works in Zarr Python.
+To dive right into this new feature, head over to our new [data type documentation page](../../user-guide/data_types.md) and read more about how this new data type system works in Zarr-Python.
 
 But perhaps you'd like to know more about the *context* for this new feature. The best way to convey that is to answer the following two questions:
 
 - What is Zarr's "data type model" anyway?
-- How did we make data types extensible in Zarr Python? And why now?
+- How did we make data types extensible in Zarr-Python? And why now?
 
 That's what the rest of this post is about.
 
 ## Zarr's data type model
 
-This section will explain how data types were declared in Zarr V2, why we did it that way, why that turned out to be problematic, and how we improved things in Zarr V3.
+This section explains how data types used to be declared in Zarr V2, why we did it that way, why that turned out to be problematic, and how we improved things in Zarr V3.
 
 ### NumPy x Zarr
 
-The Zarr format and the Zarr Python library are heavily influenced by NumPy's approach to arrays and data types. NumPy's influence is even written explicitly into the Zarr V2 specification:
+The Zarr format and the Zarr-Python library are heavily influenced by NumPy's approach to arrays and data types. NumPy's influence is even written explicitly into the Zarr V2 specification:
 
 > Simple data types are encoded within the array metadata as a string,
 > following the [NumPy array protocol type string (typestr) format](https://numpy.org/doc/stable/reference/arrays.interface.html#the-array-interface-protocol).
 >
 > -- [The Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding)
 
-On the implementation side, Zarr Python uses NumPy internally, and we expose Zarr array data to users in the form of NumPy arrays or arrays that follow the NumPy API (like [cupy arrays](https://docs.cupy.dev/en/stable/reference/ndarray.html)).
+On the implementation side, Zarr-Python uses NumPy internally, and we expose Zarr array data to users in the form of NumPy arrays or arrays that follow the NumPy API (like [cupy arrays](https://docs.cupy.dev/en/stable/reference/ndarray.html)).
 
 In some areas Zarr and NumPy fit together very well. They both describe arrays, after all. But the two projects have *very* different scopes: typical NumPy arrays live in memory of a single Python program. Zarr arrays are often persisted to external storage and accessed by many different programs, in many different programming languages, over many years.
 
 In my opinion, these fundamentally divergent design goals limit how much Zarr can borrow directly from NumPy.
 
-One of the big changes in the Zarr V3 spec was dropping NumPy compatibility in its data type definition. To inform some of the reasons for this choice, the next section will show just how tightly coupled Zarr V2 was to NumPy, and how this was ultimately problematic.
+One of the big changes in the Zarr V3 spec was dropping NumPy compatibility in its data type definition. To explain this choice, the next section will show just how tightly coupled Zarr V2 was to NumPy, and how this was ultimately problematic.
 
 ### NumPy's influence on Zarr V2
 
@@ -86,13 +89,13 @@ There are some advantages to copying NumPy data type strings:
 - Strings are JSON serializable. We can easily store these NumPy strings in Zarr metadata documents without defining a special JSON serialization procedure.
 - Using NumPy strings gives Zarr easy NumPy compatibility -- we can just call `np.dtype` on the string to get the right NumPy data type.
 
-If Zarr only supported integers and floating point numbers, maybe the story could end here. But Zarr V2 supports other data types, namely variable-length data types, (because Zarr V2 users *needed* these data types), and with these data types we see the limits of copying strings from NumPy.
+If Zarr only supported integers and floating point numbers, maybe the story could end here. But Zarr V2 supports other data types, namely variable-length data types (because Zarr V2 users *needed* these data types), and with these data types we see the limits of copying strings from NumPy.
 
 #### Variable-length data types
 
 The biggest problem with using NumPy data type strings in Zarr is that *distinct Zarr data types have the same NumPy string representation*. In other words, there are more Zarr data types than NumPy data types.
 
-Prior to NumPy 2.0 (when Zarr V2 was defined) there was no data type for an array of strings with variable length, like `["a", "bb", "ccc"]`. NumPy supported these arrays with the ["Object" data type](https://numpy.org/doc/stable/reference/arrays.scalars.html#numpy.object_), which supports arrays of arbitrary Python objects (including strings) by storing a buffer of references.
+When Zarr V2 was defined, years before NumPy 2.0, NumPy had no data type for an array of strings with variable length, like `["a", "bb", "ccc"]`. NumPy supported these arrays with the ["Object" data type](https://numpy.org/doc/stable/reference/arrays.scalars.html#numpy.object_), which supports arrays of arbitrary Python objects (including strings) by storing a buffer of references.
 
 The "Object" data type has a string identifier of `"|O"`, and "Object" data type arrays can contain *any* Python object, including but not limited to variable length strings. So two object arrays with very different contents will have the same data type identifier:
 
@@ -106,18 +109,18 @@ print(vlen_str.dtype.str)
 print(vlen_array.dtype.str)
 ```
 
-The above example is relevant because Zarr Python 2 supported arrays of variable length strings *and* arrays of variable length arrays. According to the [Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding), these two distinct data types are both declared as `"dtype": "|O"` in metadata documents (because they are both the "same" data type from NumPy's POV).
+The above example is relevant because Zarr-Python 2 supported arrays of variable length strings *and* arrays of variable length arrays. Zarr-Python 2 declared both of these distinct data types as `"dtype": "|O"` in metadata documents (because they are both the "same" data type from NumPy's POV), even though `"O"` is not one of the type codes defined in the [Zarr V2 spec](https://zarr-specs.readthedocs.io/en/latest/v2/v2.0.html#data-type-encoding).
 
 This is clearly a problem. From a Zarr point of view a variable-length array of strings is *very different* from a variable-length array of arrays. Zarr needs to store arrays on disk, and the storage procedure is very different for these two distinct data types.
 
-Zarr Python solved this with a hack: an array of variable-length strings was *operationally* defined as an array with the following configuration in metadata:
+Zarr-Python solved this with a hack: an array of variable-length strings was *operationally* defined as an array with the following configuration in metadata:
 
 - the data type is declared as `"|O"`.
 - the chunk encoding for the array included a special "variable-length UTF8" codec. This could be found either in the `filters` field or the `compressor` field.
 
 And an array of variable-length arrays was operationally defined similarly, although with a *different* special codec (one designed specifically for variable-length arrays).
 
-Clearly it's problematic if the metadata field responsible for declaring the data type for the array (`dtype`) doesn't fully declare the data type for the array in some cases! Zarr Python hacked around this by storing some data-type-specific information in the filters / compressor for an array, but this is far from ideal (and this behavior was never fully specified).
+Clearly it's problematic if the metadata field responsible for declaring the data type for the array (`dtype`) doesn't fully declare the data type for the array in some cases! Zarr-Python hacked around this by storing some data-type-specific information in the filters / compressor for an array, but this is far from ideal (and this behavior was never fully specified).
 
 ### Zarr Version 3
 
@@ -128,7 +131,7 @@ Instead, data types in Zarr V3 are declared in one of two ways:
 - as a string, like `"int64"`, which declares the signed 64-bit integer data type. Note that unlike NumPy, Zarr V3 data types are generally not defined with a byte order.
 - as a JSON object with the following form:
 
-    ```json
+    ```text
     {
      "name": <data type name>,
      "configuration": {...<data type configuration>}
@@ -141,7 +144,7 @@ This brings immediate advantages over the Zarr V2 data type model.
 
 Instead of copying NumPy, the Zarr V3 specification defines a list of core data types that all Zarr implementations ought to support. But we also think people should be able to create new data types, and we don't want to update the core Zarr V3 specification every time that happens.
 
-Instead, the Zarr community maintains the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project, which collects specification documents for community-defined data types. `zarr-extensions` is a lightweight coordination mechanism that ensures people designing their own data types can avoid name collisions with other pre-existing community-defined data types.
+That's the job of the [zarr-extensions](https://github.com/zarr-developers/zarr-extensions/) project mentioned above. It is a lightweight coordination mechanism that ensures people designing their own data types can avoid name collisions with other pre-existing community-defined data types.
 
 We also think writing data type specifications in the open will drive awareness and adoption of new data types across multiple Zarr implementations.
 
@@ -149,7 +152,7 @@ We also think writing data type specifications in the open will drive awareness
 
 By ditching the Zarr V2 string-only data type definition, we can use JSON objects to more explicitly model data types that have significant parametrization.
 
-For example, NumPy defines [two data types](https://numpy.org/doc/stable/reference/arrays.datetime.html) for temporal *moments* (`datetime64`) and *intervals* (`timedelta64`). Both of these data types are parametrized by a time unit and a scaling factor. Zarr V2 used the NumPy string representation of these data types, leading to [stringly typed](https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed) data type declarations like `"<M8[10ns]"`, which encodes a little-endian `datetime64` with a scale factor of 10 and a unit of nanoseconds.
+For example, NumPy defines [two data types](https://numpy.org/doc/stable/reference/arrays.datetime.html) for temporal *moments* (`datetime64`) and *durations* (`timedelta64`). Both of these data types are parametrized by a time unit and a scaling factor. Zarr V2 used the NumPy string representation of these data types, leading to [stringly typed](https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed) data type declarations like `"<M8[10ns]"`, which encodes a little-endian `datetime64` with a scale factor of 10 and a unit of nanoseconds.
 
 In Zarr V3, we use a much more explicit representation to express the same data type:
 
@@ -166,23 +169,23 @@ This JSON object is defined in a [published specification](https://github.com/za
 
 Defining Zarr data types in-house is good for Zarr implementations today, but we think it's also the right choice for data consumers in the future.
 
-If we kept NumPy as a dependency for Zarr V3, the Zarr ecosystem would be vulnerable to a scenario in which NumPy changes how they represent data types, which could complicate reading Zarr data written in the past.
+If the Zarr V3 spec still used NumPy's data type strings, the Zarr ecosystem would be vulnerable to a scenario in which NumPy changes how they represent data types, which could complicate reading Zarr data written in the past.
 
-That's enough about the spec story. Now we'll shift gears and talk about how we finally embraced the Zarr V3 data type model in the 3.1 release of Zarr Python.
+That's enough about the spec story. Now we'll shift gears and talk about how we finally embraced the Zarr V3 data type model in the 3.1 release of Zarr-Python.
 
-## What's changed in Zarr Python 3.1.0
+## What's changed in Zarr-Python 3.1.0
 
-We shipped [Zarr Python 3.0](https://zarr.dev/blog/zarr-python-3-release/) back in January with support for a fixed set of array data types. To get the 3.0 release out quickly, we made a lot of short-term design choices, like handling data types for Zarr V2 arrays and Zarr V3 arrays in completely separate code paths. We also relied heavily on NumPy data type classes internally.
+We shipped [Zarr-Python 3.0](https://zarr.dev/blog/zarr-python-3-release/) back in January with support for a fixed set of array data types. To get the 3.0 release out quickly, we made a lot of short-term design choices, like handling data types for Zarr V2 arrays and Zarr V3 arrays in completely separate code paths. We also relied heavily on NumPy data type classes internally.
 
 This was fast to ship, but it proved expensive in terms of technical debt -- separate code paths for V2 and V3 arrays led to code duplication, and worse, we introduced a lot of unnecessary complexity for operations that could, in principle, be represented more simply.
 
-There were other problems -- Zarr Python 3.0 did not ship with support for a few important Zarr V2 / NumPy data types, namely datetimes, timedeltas, and fixed-length UTF-32 strings. People who had used these data types with Zarr Python 2.x could not migrate to Zarr V3 until we added support for these data types.
+There were other problems -- Zarr-Python 3.0 did not ship with Zarr V3 support for a few important Zarr V2 / NumPy data types, namely datetimes, timedeltas, fixed-length UTF-32 strings, fixed-length bytes, and structured data types. People who had used these data types with Zarr-Python 2.x could not migrate to Zarr V3 until we added support for these data types.
 
 So while squashing a lot of the urgent post-3.0-release bugs, we started thinking about a coherent, extensible model for data types, since it was clear that we couldn't commit to longer-term maintenance for our initial data type model.
 
 Things got a lot more real in late January when [Nick Byrne](https://github.com/nenb/), an engineer at [OpenTeams](https://openteams.com/), drafted a [concrete proposal](https://github.com/zarr-developers/zarr-python/pull/2750) for a new data type API.
 
-Nick's proposal was hugely influential; when [Earthmover](https://earthmover.io/) contracted me to add fixed-length strings to Zarr Python, I realized that the total cost of adding a new data type to our existing data type API would, over the long term, cost more time than a full re-design. So I started work on a [pull request](https://github.com/zarr-developers/zarr-python/pull/2874) that extended Nick's ideas to as many data types as possible.
+Nick's proposal was hugely influential; when [Earthmover](https://earthmover.io/) contracted me to add fixed-length strings to Zarr-Python, I realized that the total cost of adding a new data type to our existing data type API would, over the long term, cost more time than a full re-design. So I started work on a [pull request](https://github.com/zarr-developers/zarr-python/pull/2874) that extended Nick's ideas to as many data types as possible.
 
 Through the 300+ comments on that pull request, and many more comments in the associated [discussion on the Zarr developer chat](https://ossci.zulipchat.com/#narrow/channel/423692-Zarr/topic/extensible.20dtypes), we built an API that's pretty good, or at least it's good enough for now :sweat_smile:.
 
@@ -192,13 +195,13 @@ The basic design revolves around one class per data type. Each Zarr data type cl
 
 - The *"native" data type*
 
-    This is the in-memory data type Zarr Python will use when returning decoded chunks of a Zarr array to users. Right now all the native data types are NumPy or CuPy data types, but hopefully we support more array backends in the future!
+    This is the in-memory data type Zarr-Python will use when returning decoded chunks of a Zarr array to users. Right now all the native data types are NumPy data types (CuPy arrays use NumPy data types too), but hopefully we support more array backends in the future!
 
 - The *scalar type*
 
     This is the type of the individual elements inside an array.
 
-    To illustrate how this type is not the same as the "native" data type, consider the variable-length string data type. With older versions of NumPy, the native data type is the NumPy "Object" data type; with newer versions of NumPy, we can use the [Variable-length string data type](https://numpy.org/devdocs/user/basics.strings.html#variable-width-strings). But in either case the scalar type is `str`: a plain Python string.
+    To illustrate how this type is not the same as the "native" data type, consider the variable-length string data type. With older versions of NumPy, the native data type is the NumPy "Object" data type; with newer versions of NumPy, we can use the [variable-length string data type](https://numpy.org/doc/stable/user/basics.strings.html#variable-width-strings). But in either case the scalar type is `str`: a plain Python string.
 
 Each `ZDType` defines the following behaviors:
 
@@ -246,31 +249,30 @@ print(zd.cast_scalar(10))
 print(zd.from_json_scalar(10, zarr_format=3))
 ```
 
-Adding a new data type to Zarr Python is now as simple as implementing a new `ZDType` class and registering it. That whole process is demonstrated in [this self-contained example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py).
+Adding a new data type to Zarr-Python is now as simple as implementing a new `ZDType` class and registering it. That whole process is demonstrated in [this self-contained example](https://github.com/zarr-developers/zarr-python/blob/main/examples/custom_dtype/custom_dtype.py).
 
-And that's pretty much it -- each `ZDType` defines an interface between the Zarr V2 / V3 metadata representations on one side, and in-memory python objects on the other. `ZDType` classes can be added at runtime by users, and we can ship more `ZDType` classes with Zarr Python as more community data types are minted.
+And that's pretty much it -- each `ZDType` defines an interface between the Zarr V2 / V3 metadata representations on one side, and in-memory python objects on the other. `ZDType` classes can be added at runtime by users, and we can ship more `ZDType` classes with Zarr-Python as more community data types are minted.
 
 ### New (old) data types
 
-Zarr Python 3.0 shipped without all the data types that Zarr Python 2.x supported. Zarr Python 3.1 adds full support for these data types, across Zarr V2 and V3:
+Zarr-Python 3.0 shipped without all the data types that Zarr-Python 2.x supported. Zarr-Python 3.1 adds full support for these data types, across Zarr V2 and V3:
 
 - [Fixed-length raw bytes][zarr.dtype.RawBytes]
 - [Fixed-length null-terminated bytes][zarr.dtype.NullTerminatedBytes]
-- [Variable-length bytes][zarr.dtype.VariableLengthBytes]
 - [Fixed-length UTF-32 strings][zarr.dtype.FixedLengthUTF32]
 - [Datetime64][zarr.dtype.DateTime64]
 - [Timedelta64][zarr.dtype.TimeDelta64]
 - [Structured data types][zarr.dtype.Structured]
 
-For the full list of supported data types, see the [Zarr Python docs](../../user-guide/data_types.md#list-of-data-types).
+For the full list of supported data types, see the [Zarr-Python docs](../../user-guide/data_types.md#list-of-data-types).
 
 ## What's next
 
 The Zarr V2 data type model incidentally made NumPy a soft dependency for the entire Zarr ecosystem. This proved problematic for a data format implemented in multiple languages, and it ultimately limited our ability to define new data types.
 
-The Zarr V3 spec fixed this with a *de novo* extensible data type model, but Zarr Python didn't fully implement that model until Zarr Python version 3.1. With Zarr Python 3.1 released, and the `zarr-extensions` project up and running, we're very excited to see what the Zarr community does with these long-awaited features.
+The Zarr V3 spec fixed this with a *de novo* extensible data type model, but Zarr-Python didn't fully implement that model until Zarr-Python version 3.1. With Zarr-Python 3.1 released, and the `zarr-extensions` project up and running, we're very excited to see what the Zarr community does with these long-awaited features.
 
-In the short term, we hope machine learning engineers take full advantage of Zarr for cloud-friendly, scalable array storage.
+In the short term, we hope machine learning engineers use data types like `bfloat16` to take full advantage of Zarr for cloud-friendly, scalable array storage.
 
 Longer term, there are some features we could add to the Zarr data type model.
 
@@ -286,7 +288,7 @@ Several groups of people contributed resources that enabled this work.
 
 The [Zarr spec contributors](https://github.com/zarr-developers/zarr-specs/graphs/contributors) did the foundational work of delivering a Zarr V3 specification that made this work expressible.
 
-The [Zarr Python contributors](https://github.com/zarr-developers/zarr-python/graphs/contributors) built the foundational Zarr implementation in Python, and provided extensive feedback during the development process of the work described in this post.
+The [Zarr-Python contributors](https://github.com/zarr-developers/zarr-python/graphs/contributors) built the foundational Zarr implementation in Python, and provided extensive feedback during the development process of the work described in this post.
 
 [OpenTeams](https://openteams.com/) supported Nick Byrne's invaluable work as a PR reviewer.