Skip to content
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

HDF5Archive mangles (silently) all keys in python dictionaries to strings #17

Open
HugoStrand opened this issue Aug 8, 2017 · 5 comments
Labels
bug Something isn't working

Comments

@HugoStrand
Copy link
Member

I was surprised to find that pytriqs.archive.HDF5Archive silently converts all keys in python dictionaries to strings, which of course break things expecting other python objects. See below for a small example.

I would strongly recommend that conversion of dictionaries either are fully supported, or that one gets an error when trying to store a dictionary with non-string keys. Silent conversion is very bad practice.

Best, Hugo

Here is a small example:

from pytriqs.archive import HDFArchive

my_data = {(0, 1) : 1.2345 } # dict with tuple key

# dump to disk and read again to/from hdf5
filename = "data.h5"
with HDFArchive(filename, 'w') as data: data['my_data'] = my_data
with HDFArchive(filename, 'r') as data: my_data_ref = data['my_data']

for key, value in my_data.items(): print key, value, type(key), type(value)
for key, value in my_data_ref.items(): print key, value, type(key), type(value)

for key, value_ref in my_data_ref.items():
    assert( my_data.has_key(key) )
    value = my_data[key]
    assert( value == value_ref )

resulting in

(0, 1) 1.2345 <type 'tuple'> <type 'float'>
(0, 1) 1.2345 <type 'str'> <type 'float'>
Traceback (most recent call last):
  File "triqs_dict_h5_bug.py", line 15, in <module>
    assert( my_data.has_key(key) )
AssertionError
@HugoStrand HugoStrand added the bug Something isn't working label Aug 8, 2017
@krivenko
Copy link

krivenko commented Aug 8, 2017

Hi Hugo,
This issue was discussed before, see TRIQS/triqs#220.

@HugoStrand
Copy link
Member Author

Dear Igor, Thanks for pointing this out.

Even so, I really think that HDFArchive should complain when the keys are not strings and throw an error.

In the current state one easily spends a couple of hours debugging, since the conversion is silent.

Best, H

@krivenko
Copy link

krivenko commented Aug 9, 2017

Even so, I really think that HDFArchive should complain when the keys are not strings and throw an error.

In the current state one easily spends a couple of hours debugging, since the conversion is silent.

I agree, there is an issue that should be addressed.

The actual problem is that either of the potential solutions has its downside.
Attaching type information to the keys will make archive format more complex.
On the other hand, throwing an exception will surely break some codes. For example, I can easily imagine people using integers as dictionary keys.

@HugoStrand
Copy link
Member Author

Fair enough, so a deprecation warning printout would be the middle ground solution?

@krivenko
Copy link

krivenko commented Aug 9, 2017

Fair enough, so a deprecation warning printout would be the middle ground solution?

Yes, this is probably the most reasonable thing we can do at the moment.

@Wentzell Wentzell transferred this issue from TRIQS/triqs Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants