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
Store filenames #4
Conversation
@@ -154,7 +154,7 @@ def __getitem__(self, key): | |||
if key in self.inmem: | |||
value = self.inmem[key] | |||
else: | |||
if key not in self._keys: | |||
if key not in self._keys.keys(): |
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.
The old version is probably best in my_dict
actually checks for membership in the keys. Adding the .keys()
method creates an explicit list.
I'm not entirely sure what's happening with the file not found issue (though I also haven't looked very deeply into it). During garbage collection ( |
I suspect that the coverage error in Python3 might be my fault. I think it's in master. |
I'll take a look at that error in the next day or so. Happy to merge this with this error. |
When the dict is treated like a set, it uses the set of keys. Also, list() knows how to handle dictionary view objects without an intermediate cast.
Happy to merge. Was there any behavior you wanted to test to make sure that there isn't a regression in the future? Currently there is nothing stopping someone else from coming along and unknowingly changing things back. |
Good call. I wonder why that |
It's never being triggered by any of the tests. I'm investigating that this afternoon. |
Its non-deterministic. On my local machine:
|
Filenames are stored along with keys, making old chests more portable. _keys, which was a set, is replaced with a {key -> filename} dictionary. The dictionary is dumped/loaded as a list of tuples for json compatibility, but used as a dict internally.