[Python-ideas] Identity dicts and sets

Terry Reedy tjreedy at udel.edu
Thu Jan 3 19:32:17 CET 2013


On 1/3/2013 6:51 AM, Serhiy Storchaka wrote:
> On 03.01.13 00:48, Terry Reedy wrote:

In my original, the following quote is preceded by the following snipped 
line.

"By default, equality check is identity check."

>> I don't know anything about pickling or __sizeof__, by if one uses
>> user-defined classes for nodes and edges, equality is identity,

In that context, I pretty obviously meant user-defined class with the 
default equality as identity. The contrapositive is "If equality is not 
identity, one is not using a user-defined class with default identity."

> If one uses a list, a dict, or user-defined class with defined __eq__,
> equality is not identity.

Yes, these are are examples of 'not a user-defined class with default 
identity' in which equality is not identity. I thought it was clear that 
I know about such things.

> Yes, you can use an identity dict with mutable types!

Yes, and my point was that we effectively already have such things.

class Node(): pass

Instances of Node wrap a dict as .__dict__, but are compared by wrapper 
identity rather than dict value. A set of such things is effectively an 
identity set. In 3.3+, if the instances all have the same attributes (if 
the .__dicts__ all have the same keys), there is only one (not too 
sparse) hashed list of keys for all instances and one corresponding (not 
too sparse) list of values for each instance.

Also, which I did not say before: if one instead represents nodes by a 
unique integer or string or by a list that starts with such a unique 
identifier, then equality is again effectively identity and a set (or 
sequence) of such things is effectively an identity set. This 
corresponds to a standard database table where records have keys, so 
that the identity of records is not lost when reordered or removed from 
the table.

 >> so I don't see what would be gained.

You are proposing (yet-another) dict variation for use in *python* code. 
That requires more justification than a few percent speedup in 
specialized usages. It should make python programming substantially 
easier in multiple use cases. I do not yet see this in regard to graph 
algorithm.

-- 
Terry Jan Reedy




More information about the Python-ideas mailing list