|
1 | 1 | Ensure that invocations of ``create_array`` use consistent keyword arguments, with consistent defaults.
|
2 |
| -Specifically, ``zarr.api.synchronous.create_array`` now takes a ``write_data`` keyword argument; The |
3 |
| -``create_array`` method on ``zarr.Group`` takes ``data`` and ``write_data`` keyword arguments. The ``fill_value`` |
4 |
| -keyword argument of the various invocations of ``create_array`` has been consistently set to ``None``, where previously it was either ``None`` or ``0``. |
| 2 | + |
| 3 | +- ``zarr.api.synchronous.create_array`` now takes a ``write_data`` keyword argument |
| 4 | +- The ``Group.create_array`` method takes ``data`` and ``write_data`` keyword arguments. |
| 5 | +- The functions ``api.asynchronous.create``, ``api.asynchronous.create_array`` |
| 6 | + and the methods ``Group.create_array``, ``Group.array``, had the default |
| 7 | + ``fill_value`` changed from ``0`` to the ``DEFAULT_FILL_VALUE`` value, which instructs Zarr to |
| 8 | + use the default scalar value associated with the array's data type as the fill value. These are |
| 9 | + all functions or methods for array creation that mirror, wrap or are wrapped by, another function |
| 10 | + that already has a default ``fill_value`` set to ``DEFAULT_FILL_VALUE``. This change is necessary |
| 11 | + to make these functions consistent across the entire codebase, but as this changes default values, |
| 12 | + new data might have a different fill value than expected after this change. |
| 13 | + |
| 14 | + For data types where 0 is meaningful, like integers or floats, the default scalar is 0, so this |
| 15 | + change should not be noticeable. For data types where 0 is ambiguous, like fixed-length unicode |
| 16 | + strings, the default fill value might be different after this change. Users who were relying on how |
| 17 | + Zarr interpreted ``0`` as a non-numeric scalar value should set their desired fill value explicitly |
| 18 | + after this change. |
0 commit comments