[IronPython] IronPython.Objects.List doesn't support GetHashCode()

Chris Anderson chrisan at gmail.com
Thu May 12 15:26:49 CEST 2005


I'll be the first to admit that I'm not the master of language design or 
hashtables... 
 My understanding was that the hash of an object needed to be consistent 
over the life of the object (therefore providing a way for a hashtable to 
find the bucket for it) and relatively unique (basically, that given a 
number of objects they don't all hash to the same thing).
 I believe that simply returning "1" from GetHashCode() would work just fine 
- however it would mean that hashtables would effectively become linked 
lists or linear arrays (depending on their implementation). From that model, 
returning the base CLR GetHashCode implementation for object seems 
completely reasonable... 
 The issue i'm running into is that internal data binding constructs in 
Avalon require that we push the data source for lists into a hashtable (so 
that we can manage concurrency in a reasonably performant fashion)... 
without hash support, i can never bind to lists or dictionaries from python.

On 5/12/05, Timothy Fitz <firemoth at gmail.com> wrote:
> On 5/12/05, Chris Anderson <chrisan at gmail.com> wrote:
<snip /> 
> Yes, there is harm in it. Try this in python hash([]) and you'll get
> the same TypeError. The reason is because lists shouldn't be hashed.
> List comparison is based on the items inside a list, not the instance
> of the list itself. For instance:
> 
> from copy import deepcopy
> A = [1,2]
> B = deepcopy(A)
> assert A == B
> assert id(A) != id(B)
> 
<snip /> 
> In general, mutable objects should not provide hashing functions in 
python.
<snip />
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20050512/cb3dd98d/attachment.html>


More information about the Ironpython-users mailing list