-
Notifications
You must be signed in to change notification settings - Fork 1
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
Fix: Attributes look like h5py attributes when using the pyfive backend. #6
Conversation
# method, but we only have to deal with | ||
# the case of a numpy array of strings. | ||
try: | ||
if output.dtype == object: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work ok with attributes? Is output the actual array at this point? In which case I imagine it would work fine. Coz this is all in attributes, not data, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I wonder whether implementing a check_string_dtype
method might solve my other problems with dtypes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - this is just attributes. No data arrays here!
Actually, I wonder whether implementing a check_string_dtype method might solve my other problems with dtypes?
I think implementing would indeed work. Looks straight forward: https://github.com/h5py/h5py/blob/master/h5py/h5t.pyx#L1893-L1913.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you fancy doing that in pyfive? It would be consistent with the other stuff you are cleaning up. Then this code can be more consistent h5py and we have some more support for this stuff there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bit of a can of worms.
-
The h5py
check_string_dtype
expectsh5py.h5a.AttrID
objects, whereas pyfive gives us numpy or str objects. I could delve into the h5py object to see what's in it, but I do know that it relies in thenp.dtype.metadata
mappingproxy, which is something defined elsewhere in h5py (not standard numpy), and (quote from docs) is "long undocumented and is not well supported. Some aspects of metadata propagation are expected to change in the future." -
Then there's python2 code in the function:
if vlen_kind is unicode:
(https://github.com/h5py/h5py/blob/master/h5py/h5t.pyx#L1905). I guess this works becausecython
still understands it, but our own python3 would not. Isunicode
in python2 the same asstr
in python3. Probably? Am I reading this right?
Anyway, there's enough here to make me want to not implement our own check_string_dtype
at this time.
h5netcdf/tests/test.nc
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no tests in the pull request, so what is this doing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. I didn't willfully re-make the file! I did run the unit tests. Do they recreate test.nc
, and with some bit of difference due to some different library version or other that I was using?
We should revert them, I guess
h5py
attributes when using thepyfive
backend. #5CHANGELOG.rst