Making NpzFiles behave more like dictionaries.
Hi, It's occasionally annoyed me that NpzFiles can't be swapped in transparently for an in-memory dictionary since getting at the keys requires an attribute access. Below is a patch that implements some more of the dictionary interface for the NpzFile class. Any comments as to whether this is a good/bad idea, or about the specific implementation? Regards, David Index: io.py =================================================================== --- io.py (revision 7031) +++ io.py (working copy) @@ -118,6 +118,25 @@ else: raise KeyError, "%s is not a file in the archive" % key + def __iter__(self): + return iter(self.files) + + def items(self): + return [(f, self[f]) for f in self.files] + + def iteritems(self): + return ((f, self[f]) for f in self.files) + + def keys(self): + return self.files + + def iterkeys(self): + return self.__iter__() + + def __contains__(self, key): + return self.files.__contains__(key) + + def load(file, mmap_mode=None): """ Load a pickled, ``.npy``, or ``.npz`` binary file.
Tue, 02 Jun 2009 14:55:02 -0400, David Warde-Farley wrote:
It's occasionally annoyed me that NpzFiles can't be swapped in transparently for an in-memory dictionary since getting at the keys requires an attribute access. Below is a patch that implements some more of the dictionary interface for the NpzFile class. Any comments as to whether this is a good/bad idea, or about the specific implementation?
+0 I don't see any drawbacks, and the implementation looks good. -- Pauli Virtanen
On 2-Jun-09, at 3:06 PM, Pauli Virtanen wrote:
+0
I don't see any drawbacks, and the implementation looks good.
Thanks Pauli. I realized I was missing values() and itervalues() (though I can't conceive of a scenario where I'd use them myself, I guess some code might expect them). Also I should probably make a copy of self.files in keys() to prevent it from being mutated. I've filed a ticket with the updated patch: http://projects.scipy.org/numpy/ticket/1125 David
Wed, 03 Jun 2009 16:05:51 -0400, David Warde-Farley wrote:
On 2-Jun-09, at 3:06 PM, Pauli Virtanen wrote:
+0
I don't see any drawbacks, and the implementation looks good.
Thanks Pauli. I realized I was missing values() and itervalues() (though I can't conceive of a scenario where I'd use them myself, I guess some code might expect them). Also I should probably make a copy of self.files in keys() to prevent it from being mutated.
I've filed a ticket with the updated patch:
Btw, are you able to change the status of the ticket to "needs_review"? I think this should be possible for everyone, and not restricted to admins, but I'm not 100% sure... -- Pauli Virtanen
On 3-Jun-09, at 5:01 PM, Pauli Virtanen wrote:
Btw, are you able to change the status of the ticket to "needs_review"? I think this should be possible for everyone, and not restricted to admins, but I'm not 100% sure...
Sorry, yes I am. I had just forgotten. David
On 3-Jun-09, at 5:01 PM, Pauli Virtanen wrote:
Btw, are you able to change the status of the ticket to "needs_review"? I think this should be possible for everyone, and not restricted to admins, but I'm not 100% sure...
Sorry Pauli, seems I _don't_ have permission on the numpy trac to change ticket status. The radio button shows up but then it gives me a "Warning: No permission to change ticket fields." David
2009/6/4 David Warde-Farley <dwf@cs.toronto.edu>:
Sorry Pauli, seems I _don't_ have permission on the numpy trac to change ticket status. The radio button shows up but then it gives me a "Warning: No permission to change ticket fields."
Should be fixed. Cheers Stéfan
On 4-Jun-09, at 9:28 AM, Stéfan van der Walt wrote:
2009/6/4 David Warde-Farley <dwf@cs.toronto.edu>:
Sorry Pauli, seems I _don't_ have permission on the numpy trac to change ticket status. The radio button shows up but then it gives me a "Warning: No permission to change ticket fields."
Should be fixed.
Thanks Stefan. David
participants (3)
-
David Warde-Farley -
Pauli Virtanen -
Stéfan van der Walt