towards new h5netcdf/netcdf4 features#9509
Conversation
kmuehlbauer
force-pushed
the
h5netcdf-new-features
branch
from
f592de3 to
7845e81
Compare
| Invalid netCDF files | ||
| ~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| The library ``h5netcdf`` allows writing some dtypes (booleans, complex, ...) that aren't |
There was a problem hiding this comment.
It boils down, that we are approaching feature equality between netcdf4-python and h5netcdf. It seems, that only reference objects can't be handled by netcdf-c.
There was a problem hiding this comment.
Todo: check boolean enums
for more information, see https://pre-commit.ci
kmuehlbauer
force-pushed
the
h5netcdf-new-features
branch
from
801216c to
b78c42e
Compare
| compute: bool = True, | ||
| multifile: Literal[False] = False, | ||
| invalid_netcdf: bool = False, | ||
| auto_complex: bool | None = None, |
There was a problem hiding this comment.
What does auto_complex = None mean? Is it the same as auto_complex = False?
EDIT: Ah, to avoid passing the argument to h5netcdf? But invalid_netcdf is just a plain bool, so is that handled differently for netCDF4?
Should we also consider defaulting to True? I'm definitely interested in finding out if there are any cases where this results in unwanted behaviour
There was a problem hiding this comment.
Yeah, not sure, if I handled that correctly. It's more or less a security measure against feeding the kwarg to versions which can't handle those yet. I think this was the simplest solution without adding a whole bunch of boilerplate code. But maybe there is an easier solution to that.
Co-authored-by: Peter Hill <zed.three@gmail.com>
|
Thanks @ZedThree for taking the time to review. I've added couple of comments. |
|
@pydata/xarray This seems to be ready now for review. This brings in adaptions for changes ongoing in h5netcdf/netcdf4-python wrt complex numbers and enums. |
kmuehlbauer
changed the title
ZedThree
left a comment
ZedThree
left a comment
There was a problem hiding this comment.
LGTM, thanks @kmuehlbauer!
I do think it would be clearer with having auto_complex just be bool (I don't think allowing it to be None gets us anything over setting it False by default), and with a check that when setting it we are using the netcdf4 engine, but that's a minor quibble.
|
Upstream and upstream mypy failures are unrelated. I'm going to merge this the next day. |
2 participants
whats-new.rstapi.rst