2. Is there interest inuv-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

I tried removing thecovariant=True stuff in98404bd 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"hasincompatibletype"Int16";expected"ZDType[dtype[generic], generic | str | bytes]"  [arg-type]

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

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.

@joshmoore see also#3512

I tried removing the covariant=True stuff in98404bd 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 ofcovariant (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.

based onthese docs, my feeling is that in the context ofZDType[A, B],A andB should be inferred ascontravariant covariant iffA andB only appear as return types of theZDType methods, which I'm pretty sure is the case? Since I needed to do that in 3.11 to make mypy happy.

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:

classBase1: ...classSubBase1(Base1): ...classSubSubBase1(SubBase1): ...classBase2: ...classSubBase2(Base2): ...classSubSubBase2(SubBase2): ...classF[T:Base1,S:Base2]: ...classFSub(F[SubBase1,SubBase2]): ...classFSubSub(F[SubSubBase1,SubSubBase2]): ...typeGType=Fg:GType=FSubSub()

So maybe I'm misunderstanding.

only appear as return types of the ZDType methods

Totally misunderstood this in our context, but I think I got it now! I madedtype_cls not dependent on the generic (I think)86095bb#diff-bb2825e8577e13fd91c0cab0696d2c2736686dc7995484285290b6bee5c4190aR73