Merge branch 'remove-vlen-utf8-warning' of https://github.com/d-v-b/zarr-python into remove-vlen-utf8-warning

Author: d-v-b

.github/ISSUE_TEMPLATE/release-checklist.md

@@ -25,6 +25,7 @@ assignees: ''
   - [ ] All tests pass in the ["GPU Tests" workflow](https://github.com/zarr-developers/zarr-python/actions/workflows/gpu_test.yml).
   - [ ] All tests pass in the ["Hypothesis" workflow](https://github.com/zarr-developers/zarr-python/actions/workflows/hypothesis.yaml).
   - [ ] Check that downstream libraries work well (maintainers can make executive decisions about whether all checks are required for this release).
+    - [ ] numcodecs
     - [ ] Xarray (@jhamman @dcherian @TomNicholas)
         - Zarr's upstream compatibility is tested via the [Upstream Dev CI worklow](https://github.com/pydata/xarray/actions/workflows/upstream-dev-ci.yaml).
         - Click on the most recent workflow and check that the `upstream-dev` job has run and passed. `upstream-dev` is not run on all all workflow runs.

changes/+c563f4d4.bugfix.rst

@@ -0,0 +1 @@
+Register 'gpu' marker with pytest for downstream StoreTests.

changes/2819.chore.rst

@@ -0,0 +1,2 @@
+Expand the data type docs to include a demonstration of the ``parse_data_type`` function.
+Expand the docstring for the ``parse_data_type`` function.

changes/3249.doc.rst

@@ -0,0 +1 @@
+Ensure that all abstract methods of ``ZDType`` raise a ``NotImplementedError`` when invoked.

changes/3251.fix.rst

@@ -18,7 +18,7 @@ Funding
 -------
 The project is fiscally sponsored by `NumFOCUS <https://numfocus.org/>`_, a US
 501(c)(3) public charity, and development is supported by the
-`MRC Centre for Genomics and Global Health <https://www.cggh.org>`_
+`MRC Centre for Genomics and Global Health <https://github.com/cggh/>`_
 and the `Chan Zuckerberg Initiative <https://chanzuckerberg.com/>`_.
 
 .. _NumCodecs: https://numcodecs.readthedocs.io/

docs/about.rst

@@ -167,8 +167,17 @@ def skip_submodules(
 # documentation.
 html_theme_options = {
     "github_url": "https://github.com/zarr-developers/zarr-python",
-    "twitter_url": "https://twitter.com/zarr_dev",
     "icon_links": [
+        {
+            "name": "Bluesky",
+            "url": "https://bsky.app/profile/zarr.dev",
+            "icon": "fa-brands fa-bluesky",
+        },
+        {
+            "name": "Mastodon",
+            "url": "https://fosstodon.org/@zarr",
+            "icon": "fa-brands fa-mastodon",
+        },
         {
             "name": "Zarr Dev",
             "url": "https://zarr.dev/",
@@ -178,7 +187,6 @@ def skip_submodules(
     ],
     "collapse_navigation": True,
     "navigation_with_keys": False,
-    "announcement": "Zarr-Python 3 is here! Check out the release announcement <a href='https://zarr.dev/blog/zarr-python-3-release/'>here.</a>",
 }
 
 # Add any paths that contain custom themes here, relative to this directory.

docs/conf.py

@@ -8,7 +8,24 @@ Release notes
 
 Features
 ~~~~~~~~
-
+- Ensure that invocations of ``create_array`` use consistent keyword arguments, with consistent defaults.
+
+  ``zarr.api.synchronous.create_array`` now takes a ``write_data`` keyword argument
+  The ``Group.create_array`` method takes ``data`` and ``write_data`` keyword arguments.
+  The functions ``api.asynchronous.create``, ``api.asynchronous.create_array``
+  and the methods ``Group.create_array``, ``Group.array``, had the default
+  ``fill_value`` changed from ``0`` to the ``DEFAULT_FILL_VALUE`` value, which instructs Zarr to
+  use the default scalar value associated with the array's data type as the fill value. These are
+  all functions or methods for array creation that mirror, wrap or are wrapped by, another function
+  that already has a default ``fill_value`` set to ``DEFAULT_FILL_VALUE``. This change is necessary
+  to make these functions consistent across the entire codebase, but as this changes default values,
+  new data might have a different fill value than expected after this change.
+
+  For data types where 0 is meaningful, like integers or floats, the default scalar is 0, so this
+  change should not be noticeable. For data types where 0 is ambiguous, like fixed-length unicode
+  strings, the default fill value might be different after this change. Users who were relying on how
+  Zarr interpreted ``0`` as a non-numeric scalar value should set their desired fill value explicitly
+  after this change.
 - Added public API for Buffer ABCs and implementations.
 
   Use :mod:`zarr.buffer` to access buffer implementations, and

docs/release-notes.rst

@@ -409,4 +409,47 @@ We want to avoid a situation where the same native data type matches multiple Za
 a NumPy data type should *uniquely* specify a single Zarr data type. But data type resolution is
 dynamic, so it's not possible to statically guarantee this uniqueness constraint. Therefore, we
 attempt data type resolution against *every* data type class, and if, for some reason, a native data
-type matches multiple Zarr data types, we treat this as an error and raise an exception.
+type matches multiple Zarr data types, we treat this as an error and raise an exception.
+
+If you have a NumPy data type and you want to get the corresponding ``ZDType`` instance, you can use
+the ``parse_data_type`` function, which will use the dynamic resolution described above. ``parse_data_type``
+handles a range of input types:
+
+- NumPy data types:
+
+  .. code-block:: python
+
+    >>> import numpy as np
+    >>> from zarr.dtype import parse_data_type
+    >>> my_dtype = np.dtype('>M8[10s]')
+    >>> parse_data_type(my_dtype, zarr_format=2)
+    DateTime64(endianness='big', scale_factor=10, unit='s')
+
+
+- NumPy data type-compatible strings:
+
+  .. code-block:: python
+
+    >>> dtype_str = '>M8[10s]'
+    >>> parse_data_type(dtype_str, zarr_format=2)
+    DateTime64(endianness='big', scale_factor=10, unit='s')
+
+- ``ZDType`` instances:
+
+  .. code-block:: python
+
+    >>> from zarr.dtype import DateTime64
+    >>> zdt = DateTime64(endianness='big', scale_factor=10, unit='s')
+    >>> parse_data_type(zdt, zarr_format=2) # Use a ZDType (this is a no-op)
+    DateTime64(endianness='big', scale_factor=10, unit='s')
+
+- Python dictionaries (requires ``zarr_format=3``). These dictionaries must be consistent with the
+  ``JSON`` form of the data type:
+
+  .. code-block:: python
+
+    >>> dt_dict = {"name": "numpy.datetime64", "configuration": {"unit": "s", "scale_factor": 10}}
+    >>> parse_data_type(dt_dict, zarr_format=3)
+    DateTime64(endianness='little', scale_factor=10, unit='s')
+    >>> parse_data_type(dt_dict, zarr_format=3).to_json(zarr_format=3)
+    {'name': 'numpy.datetime64', 'configuration': {'unit': 's', 'scale_factor': 10}}

docs/user-guide/data_types.rst

@@ -138,6 +138,7 @@ exclude_lines = [
 [tool.coverage.run]
 omit = [
     "bench/compress_normal.py",
+    "src/zarr/testing/conftest.py",  # only for downstream projects
 ]
 
 [tool.hatch]
@@ -455,3 +456,6 @@ issue_format = ":issue:`{issue}`"
 
 [tool.codespell]
 ignore-words-list = "astroid"
+
+[project.entry-points.pytest11]
+zarr = "zarr.testing"