chore: spec0 compat (python 3.14 compat, numpy 2 min, python 3.12 min)

[ilan-gold]

Sorry if someone already started this! I didn't see it in the repo and I was trying to play around with python 3.14 until I realized the feature I was interested in had actually been released in 3.13. So just pushing here if anyone wants to pick it up (or I can finish depending on the workload).

Fixes #3512

Some questions:

1. I don't think cupy is 3.14 compat yet: https://github.com/cupy/cupy/issues/9346 but does this matter? Does zarr promise the same level of python support across devices
2. Is there interest in uv-ifying the CI? Blockers?

Locally most tests pass, and the ones that don't looked a bit me-specific (for example, a numcodecs-related test though I had python 2.18 installed? Need to look into that).

TODO:

• [ ] Add unit tests and/or doctests in docstrings
• [ ] Add docstrings and API docs for any new/modified user-facing classes and functions
• [ ] New/modified features documented in docs/user-guide/*.md
• [ ] Changes documented as a new file in changes/
• [ ] GitHub Actions have all passed
• [ ] Test coverage is 100% (Codecov passes)

[d-v-b]

2. Is there interest in uv-ifying the CI? Blockers?

i'm ok with uv-fying things. we are using hatch for defining a local test matrix, but we don't have to use that in ci

[ilan-gold]

I tried removing the covariant=True stuff in https://github.com/zarr-developers/zarr-python/pull/3564/commits/98404bdc34026ab8d6e6c5c83cffaa033c69c654 but got some strange errors, which I imagine have to do with my lack of knowledge of numpy dtype inheritance i.e., things like:

tests/test_metadata/test_v2.py:224: error: Argument "dtype" to "ArrayV2Metadata" has incompatible type "Int16"; expected "ZDType[dtype[generic], generic | str | bytes]"  [arg-type]

would love to understand this! I will try to look into it soon

[joshmoore]

As a side note, recently there was a request (@d-v-b, do you remember where?) of considering using the PSF versioning (https://devguide.python.org/versions/) rather than the SPEC. Just mentioning in case it has an impact on when we would decide to drop, etc.

[d-v-b]

@joshmoore see also https://github.com/zarr-developers/zarr-python/issues/3512

[ilan-gold]

I tried removing the covariant=True stuff in https://github.com/zarr-developers/zarr-python/commit/98404bdc34026ab8d6e6c5c83cffaa033c69c654 but got some strange errors

To clarify, the reason I find them strange is that the python docs make it seem like you can just get rid of covariant (and if you can't you're misusing it). Maybe I misunderstood. I'll try to look into it, but just figured I'd document my stopping point.

[d-v-b]

based on these docs, my feeling is that in the context of ZDType[A, B], A and B should be inferred as ~~contravariant~~ covariant iff A and B only appear as return types of the ZDType methods, which I'm pretty sure is the case? Since I needed to do that in 3.11 to make mypy happy.

[ilan-gold]

iff A and B only appear as return types of the ZDType methods

I feel quite lost here - I would think similar but this seems to work (maybe I'm missing something) whereas the (more complicated) zarr-python one doesn't:

class Base1: ...
class SubBase1(Base1): ...
class SubSubBase1(SubBase1): ...

class Base2: ...
class SubBase2(Base2): ...
class SubSubBase2(SubBase2): ...

class F[T: Base1, S: Base2]: ...

class FSub(F[SubBase1, SubBase2]): ...

class FSubSub(F[SubSubBase1, SubSubBase2]): ...

type GType = F

g: GType = FSubSub()

So maybe I'm misunderstanding.

[ilan-gold]

only appear as return types of the ZDType methods

Totally misunderstood this in our context, but I think I got it now! I made dtype_cls not dependent on the generic (I think) https://github.com/zarr-developers/zarr-python/pull/3564/commits/86095bbdcaf487ecb22d4518c0eb6e453758acae#diff-bb2825e8577e13fd91c0cab0696d2c2736686dc7995484285290b6bee5c4190aR73

[codecov[bot]]

Codecov Report

:x: Patch coverage is 11.47541% with 108 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 59.87%. Comparing base (ee0e69a) to head (b934471).

Files with missing lines	Patch %	Lines
src/zarr/abc/codec.py	10.00%	9 Missing :warning:
src/zarr/core/dtype/wrapper.py	0.00%	9 Missing :warning:
src/zarr/core/sync.py	0.00%	8 Missing :warning:
src/zarr/core/array.py	0.00%	7 Missing :warning:
src/zarr/storage/_utils.py	12.50%	7 Missing :warning:
src/zarr/core/dtype/npy/complex.py	14.28%	6 Missing :warning:
src/zarr/core/dtype/npy/float.py	14.28%	6 Missing :warning:
src/zarr/core/common.py	0.00%	5 Missing :warning:
src/zarr/core/dtype/npy/int.py	0.00%	5 Missing :warning:
src/zarr/core/indexing.py	0.00%	5 Missing :warning:
... and 20 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3564      +/-   ##
==========================================
+ Coverage   59.14%   59.87%   +0.73%     
==========================================
  Files          86       86              
  Lines       10172    10142      -30     
==========================================
+ Hits         6016     6073      +57     
+ Misses       4156     4069      -87     

Files with missing lines	Coverage Δ
src/zarr/core/buffer/core.py	30.34% <100.00%> (ø)
src/zarr/core/dtype/npy/common.py	63.70% <ø> (+1.99%)	:arrow_up:
src/zarr/testing/stateful.py	98.84% <100.00%> (-0.01%)	:arrow_down:
src/zarr/types.py	100.00% <100.00%> (ø)
src/zarr/abc/numcodec.py	16.66% <0.00%> (+1.28%)	:arrow_up:
src/zarr/abc/store.py	36.87% <0.00%> (ø)
src/zarr/api/asynchronous.py	73.89% <0.00%> (+1.69%)	:arrow_up:
src/zarr/_compat.py	0.00% <0.00%> (ø)
src/zarr/core/chunk_key_encodings.py	33.82% <0.00%> (ø)
src/zarr/core/dtype/__init__.py	30.00% <0.00%> (ø)
... and 24 more

... and 3 files with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.