[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