From: Chris Mellon <[EMAIL PROTECTED]>
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







-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to