Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

Identity dictionnary

 

 

Python python RSS feed   Index | Next | Previous | View Threaded


jsatjeannot.org

Feb 28, 2004, 9:10 PM

Post #1 of 6 (641 views)
Permalink
Identity dictionnary

Hi !

I'm trying to create an object to be used as a key in a dictionary,
where comparison (for key retrieval) would be done by 'is' instead of
__eq__.
(__eq__ is defined in this object, but serve another purpose and does
not return a boolean).

Is defining __hash__ as id(self) sufficient to guarantee that __eq__
will never be called by the dict implementation ? (it seems to work in
practice)
If not, how to ensure __eq__ will never be called ?

Thank you very much in advance !

Regards,

js


maxatalcyone.com

Feb 28, 2004, 9:15 PM

Post #2 of 6 (623 views)
Permalink
Identity dictionnary [In reply to]

Jean-Sebastien Roy wrote:

> I'm trying to create an object to be used as a key in a dictionary,
> where comparison (for key retrieval) would be done by 'is' instead of
> __eq__.
> (__eq__ is defined in this object, but serve another purpose and does
> not return a boolean).

Why would you override __eq__ in such a bizarre way?

--
__ Erik Max Francis && max [at] alcyone && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ You must surely know / If man made Heaven, then man made Hell
-- Level 42


jsatjeannot.org

Feb 28, 2004, 9:30 PM

Post #3 of 6 (625 views)
Permalink
Identity dictionnary [In reply to]

In article <40414A60.F5F64A96 [at] alcyone>,
Erik Max Francis <max [at] alcyone> wrote:

> Jean-Sebastien Roy wrote:
>
> > I'm trying to create an object to be used as a key in a dictionary,
> > where comparison (for key retrieval) would be done by 'is' instead of
> > __eq__.
> > (__eq__ is defined in this object, but serve another purpose and does
> > not return a boolean).
>
> Why would you override __eq__ in such a bizarre way?

For example to do symbolic calculation where a == b is an expression
instead of a comparison.

I should add a precision to my question:
I found a post by Tim Peters (on 2001-07-08) that said:

> no comparison is done unless the full hash codes are equal

It seems to be exactly what I need, but is it a guarantee or will it
change in the next versions ?

Regards,

js


bobatredivi.com

Feb 28, 2004, 9:30 PM

Post #4 of 6 (626 views)
Permalink
Identity dictionnary [In reply to]

On 2004-02-28 21:05:48 -0500, Jean-Sebastien Roy <js [at] jeannot> said:

> I'm trying to create an object to be used as a key in a dictionary,
> where comparison (for key retrieval) would be done by 'is' instead of
> __eq__.
> (__eq__ is defined in this object, but serve another purpose and does
> not return a boolean).
>
> Is defining __hash__ as id(self) sufficient to guarantee that __eq__
> will never be called by the dict implementation ? (it seems to work in
> practice)
> If not, how to ensure __eq__ will never be called ?

I don't believe your assumption about dict is correct. A typical dict
is not going to have 2**32 slots in it, so you will eventually get a
collision, which will call __eq__ unless the key you're getting happens
to be the first item in that slot (it think uses object identity first
as an optimization and for sanity, though I have not looked at the
source).

What you might want is a special kind of container, not a special kind
of object to use as keys to a dict:

class identitymap(object):
def __init__(self):
self._dict = {}

def __getitem__(self, item):
return self._dict[id(item)][1]

def __setitem__(self, item, value):
self._dict[id(item)] = (item, value)

... etc.

I have used a data structure such as this before for similar reasons
(an attempt at pure python transparent object persistence..).

-bob


jsatjeannot.org

Feb 28, 2004, 9:50 PM

Post #5 of 6 (628 views)
Permalink
Identity dictionnary [In reply to]

In article <2004022821314075249%bob [at] redivico>,
Bob Ippolito <bob [at] redivi> wrote:

> > Is defining __hash__ as id(self) sufficient to guarantee that __eq__
> > will never be called by the dict implementation ? (it seems to work in
> > practice)
> > If not, how to ensure __eq__ will never be called ?
>
> I don't believe your assumption about dict is correct. A typical dict
> is not going to have 2**32 slots in it, so you will eventually get a
> collision, which will call __eq__ unless the key you're getting happens
> to be the first item in that slot (it think uses object identity first
> as an optimization and for sanity, though I have not looked at the
> source).

A few years ago, Tim Peters said that == what not called unless __hash__
are equals (whatever small the number of slots is (quite strange indeed,
but why not ?)).

But that may not be true anymore (that's why I asked).

> What you might want is a special kind of container, not a special kind
> of object to use as keys to a dict:
>
> class identitymap(object):
> def __init__(self):
> self._dict = {}
>
> def __getitem__(self, item):
> return self._dict[id(item)][1]
>
> def __setitem__(self, item, value):
> self._dict[id(item)] = (item, value)
>
> ... etc.
>
> I have used a data structure such as this before for similar reasons
> (an attempt at pure python transparent object persistence..).

I initialy ruled out reimplementing a special dictionnary because I'm a
bit worried about the performance, but that's a nice solution : thanks !
I'll probably go with it.

Regards,

js


jepleratunpythonic.net

Feb 29, 2004, 10:42 AM

Post #6 of 6 (625 views)
Permalink
Identity dictionnary [In reply to]

You might consider defining a mapping which appears to be {item: value}
but is internally {hash(item): (item, value)}. You might be able to
subclass dict or start with UserDict to do this. This will certainly
avoid the problem of ever calling item.__eq__ when doing an operation on
the map, without relying on stuff that is poorly documented at best and
implementation-specific or just plain unreliable at worst.

Jeff

Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.