-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"readers" or "parsers" or what should we call them? #239
Comments
What about "get_metadata"? That explicitly says what the function does, and it can live comfortably beside functions that read array data. |
@douglatornell that certainly clearly describes what they do! I just don't know what the corresponding noun would be, |
Perhaps I'm not understanding the nuances of the the API. In
for example? But do you need to pass a function name at that level? Why not
and do the dispatching to the appropriate |
Not quite -
I do think we want to support that. There are a few common file formats that are parseable to the zarr model, plus a long tail of niche formats that are also parseable to the zarr model (see #218). We should ship readers for the common ones bundled here, but allows users to plug their own readers in.
In general I feel like we should be trying to move towards an entrypoint system, analogous to |
I'm currently calling the functions that extract the metadata from a specific filetype (or many filetypes in kerchunk's case) "readers".
I feel like "reader" implies that they read actual array data into memory, but it doesn't do that. It's also confusing alongside Zarr "readers", which actually do read array data into memory
But is there a less overloaded term? e.g:
As of #231 these currently all live in a module called
virtualizarr.readers
.We also have
virtualizarr.writers
, but that's less of a problem given that (a) there will probably only ever be two of these, (b) there aren't existing xarray backends you could get this confused with, and (c) you are writing metadata, it's not a bad term for it.(Related to pydata/xarray#9491, thought of this whilst proposing the API in #238)
The text was updated successfully, but these errors were encountered: