You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We seem to be converging on using a leading underscore to indicate private modules. Should we do this for zarr.core or can we simply document the intent of the module?
I had a quick go, and there seem to be bits that need to be public (at least zarr.core.config, zarr.core.buffer.Buffer). Making the whole of core private is going to need someone who knows the codebase well enough (definitely not me 😄) to know what should be public going through carefully and decided what should be public and what should be private.
@dstansby - what makes you think zarr.core.config needs to be public? The intent, as I see it, is just that zarr.core.config.config is public which is why it is available as zarr.config.
@normanrz - do you think we could move zarr.core.buffer to zarr.buffer? The Buffer ABC seems like it actually belongs in the abc module.
what makes you think zarr.core.config needs to be public?
There's user facing documentation in the docstring, but maybe that should now be deleted in favour of the user guide? It looks like BadConfigError isn't used so can be removed, but I think Config should be user facing as it's the type of zarr.config, so maybe that could move to zarr.Config?
This came up again in #2876 (review). I'm going to reopen this and look into how we could move everything to zarr._core and deprecate the module with a warning.
Assuming we are all aligned on the value of making core explicitly private by renaming it to _core, do we think this change would fit in a 3.1 release?
Once that's released we can (conditionally) update the imports in numcodecs to use the public API (and IIRC Icechunk had some references to zarr.core.buffer too)
Then once numcodecs has a public release with that we can begin the deprecation.
Activity
dstansby commentedon Jan 3, 2025
Is it intended to be private? If so, I'd definitely add a leading underscore to mark it as private.
jhamman commentedon Jan 3, 2025
Yes, the intent is to make it private.
dstansby commentedon Jan 3, 2025
I had a quick go, and there seem to be bits that need to be public (at least
zarr.core.config,zarr.core.buffer.Buffer). Making the whole of core private is going to need someone who knows the codebase well enough (definitely not me 😄) to know what should be public going through carefully and decided what should be public and what should be private.jhamman commentedon Jan 3, 2025
I can take this on.
dstansby commentedon Jan 4, 2025
As some small first steps I cleaned up
zarr.core.buffer(#2641) andzarr.core.metadata(#2642)jhamman commentedon Jan 6, 2025
@dstansby - what makes you think
zarr.core.configneeds to be public? The intent, as I see it, is just thatzarr.core.config.configis public which is why it is available aszarr.config.@normanrz - do you think we could move
zarr.core.buffertozarr.buffer? TheBufferABC seems like it actually belongs in theabcmodule.dstansby commentedon Jan 6, 2025
There's user facing documentation in the docstring, but maybe that should now be deleted in favour of the user guide? It looks like
BadConfigErrorisn't used so can be removed, but I thinkConfigshould be user facing as it's the type ofzarr.config, so maybe that could move tozarr.Config?normanrz commentedon Jan 6, 2025
Yes, we could do that. And yes, the
BufferandNDBuffermake sense in theabcmodule.jhamman commentedon Jan 7, 2025
Part 1 done here -> #2664
jhamman commentedon Jan 7, 2025
update: a fairly major gotcha, see this comment comment...
https://github.com/zarr-developers/numcodecs/blob/6c0ea0f43788f22e4ad5d6655862c6c212a0dece/numcodecs/zarr3.py#L51-L54
TomAugspurger commentedon Mar 28, 2025
This came up again in #2876 (review). I'm going to reopen this and look into how we could move everything to
zarr._coreand deprecate the module with a warning.d-v-b commentedon Apr 30, 2025
Assuming we are all aligned on the value of making
coreexplicitly private by renaming it to_core, do we think this change would fit in a 3.1 release?TomAugspurger commentedon Jun 7, 2025
xref #2876.
Once that's released we can (conditionally) update the imports in numcodecs to use the public API (and IIRC Icechunk had some references to
zarr.core.buffertoo)Then once numcodecs has a public release with that we can begin the deprecation.