Codecov Report

❌ Patch coverage is97.19626% with3 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.54%. Comparing base (a26926c) to head (3e119a9).

@@           Coverage Diff           @@##             main    #3355   +/-   ##=======================================  Coverage   94.54%   94.54%           =======================================  Files          78       80    +2       Lines        9423     9467   +44     =======================================+ Hits         8909     8951   +42- Misses        514      516    +2

The trouble with defining objects in two places (here,zarr.types andzarr.core.types) is duplication, and also means we end up importing stuff in the tests from the private place (zarr.core.types here) instead of the public place (zarr.types here), which in the past has prevented us from noticing a change in the public API (zarr.types here) because we're not actually using it in any of our tests.

To prevent this, could we either:

1. Make all the types public and just put them inzarr.types
2. Put all types inzarr.types, but make some private with a leading underscore in their name

?

Related, there are types that are inzarr.core.types that are used in the public API (at leastShapeLike, I'm sure many others too). If a type is used in the public API, it should be publicly documented, so there needs to be re-evaluation of what is public/private types here.

Related, there are types that are inzarr.core.types that are used in the public API (at leastShapeLike, I'm sure many others too). If a type is used in the public API, it should be publicly documented, so there needs to be re-evaluation of what is public/private types here.

that might be the first step to refining this PR -- we should figure out exactly which types are public. Definitely anything used as an annotation of a public function signature should be public. In this case, these types should be defined just once inzarr.types. All other private types can be defined wherever is convenient for them, which could bezarr.core.types but we could also have private, dtype-specific types inzarr.core.dtype, for example

oops, I forgot that#3304 also adds atypes module. ignore this PR until#3304 is sorted out