storing meta data on dictionary keys

Andreas Kraemer akraemer at sbcglobal.net
Tue Oct 9 20:37:33 EDT 2007


From: Chris Mellon <arkanes at gmail.com>
Sent: Tuesday, October 9, 2007 1:51:04 PM

> Because, by definition, if you have the key then you don't need to get
> it from the dict. What you're doing here is conflating 2 mappings into
> one: string value->person and person->values.  Use 2 explicit dicts to
> make it clear what you're going, or use one dict and store a tuple of
> values: person, friends = d["John"].

No, that was not the point.

I don't want the meta data to be used in the dictionary look-up, and in fact I want to be able to modify or delete it later w/o affecting dictionary look-up. In the toy example "John" and Str("John") are two different objects that map to the same value in the dictionary, and "John" == Str("John") is True, since class Str(str)  inherits __hash__() and __eq__() from str. IOW, if John dyes his hair, his friends shouldn't change :-)

Apart from this silly example I really encountered this issue when using the networkx library. As I mentioned, graph nodes are stored as dictionary keys there, i.e. nodes can be arbitrary objects with the only requirement to be hashable, and I am stuck with this data structure when using the library. In my example nodes are uniquely identified by their name (a string) but may carry other attributes, like their display color and shape, that are not used to identify a node. Therefore, I thought, subclassing str would be the simplest, most straightforward structure for a node object. 

Of course there are workarounds (e.g. get all keys with keys()), but I thought something similar to a get_key() dictionary method would be the easiest way to retrieve the actually stored key object, and I was just surprised to discover that no such method does exist ....

-Andreas







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20071009/8bc82c8b/attachment.html>


More information about the Python-list mailing list