Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #16854 > unrolled thread

Re: adding elements to set

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: adding elements to set Chris Angelico <rosuav@gmail.com> - 2011-12-09 04:37 +1100
    Re: adding elements to set Duncan Booth <duncan.booth@invalid.invalid> - 2011-12-08 18:54 +0000
      Re: adding elements to set Terry Reedy <tjreedy@udel.edu> - 2011-12-08 21:33 -0500

#16854 — Re: adding elements to set

On Fri, Dec 9, 2011 at 4:32 AM, Peter Otten <__peter__@web.de> wrote:
> The only thing that has changed (in 2.7) is the algorithm to calculate the
> hash value. The bits are rotated to turn the four least significant bits
> into the most signicant ones. According to a comment in Objects/objects.c
> the change leads to fewer hash collisions.

Interesting, but what I saw was this:

>>> class C(object):

   def __init__(self, x):
       self.x = x

   def __eq__(self, other):
       return self.x == other.x

>>> s=set()
>>> c1=C(1)
>>> s.add(c1)
Traceback (most recent call last):
  File "<pyshell#163>", line 1, in <module>
    s.add(c1)
TypeError: unhashable type: 'C'

(This is in IDLE from Python 3.2 on Windows.)

However, s.add(object()) works fine. So subclasses don't get that.
Odd. Makes sense though - you can't get this unexpected behaviour as
easily.

ChrisA

[toc] | [next] | [standalone]

#16861

Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Dec 9, 2011 at 4:32 AM, Peter Otten <__peter__@web.de> wrote:
>> The only thing that has changed (in 2.7) is the algorithm to
>> calculate the hash value. The bits are rotated to turn the four least
>> significant bits into the most signicant ones. According to a comment
>> in Objects/objects.c the change leads to fewer hash collisions.
> 
> Interesting, but what I saw was this:
> 
>>>> class C(object):
> 
>    def __init__(self, x):
>        self.x = x
> 
>    def __eq__(self, other):
>        return self.x == other.x
> 
>>>> s=set()
>>>> c1=C(1)
>>>> s.add(c1)
> Traceback (most recent call last):
>   File "<pyshell#163>", line 1, in <module>
>     s.add(c1)
> TypeError: unhashable type: 'C'
> 
> (This is in IDLE from Python 3.2 on Windows.)
> 
> However, s.add(object()) works fine. So subclasses don't get that.
> Odd. Makes sense though - you can't get this unexpected behaviour as
> easily.
> 
Yes, the documentation describes this although I don't think anything 
highlights that it is a change from Python 2.x:

[http://docs.python.org/py3k/reference/datamodel.html]

> If a class does not define an __eq__() method it should not define a
> __hash__() operation either; if it defines __eq__() but not
> __hash__(), its instances will not be usable as items in hashable
> collections. If a class defines mutable objects and implements an
> __eq__() method, it should not implement __hash__(), since the
> implementation of hashable collections requires that a key’s hash
> value is immutable (if the object’s hash value changes, it will be in
> the wrong hash bucket). 

So in Python 2.x you could define __eq__ and get the default __hash__ which 
would break dictionaries. With Python 3.x defining __eq__ will disable the 
default __hash__ although if you subclass a class that has both methods you 
could still get in a mess by redefining one without the other.


-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#16892

On 12/8/2011 1:54 PM, Duncan Booth wrote:

> Yes, the documentation describes this although I don't think anything
> highlights that it is a change from Python 2.x:
>
> [http://docs.python.org/py3k/reference/datamodel.html]

The Python 3 docs are 're-based' on 3.0, with change notes going forward 
from that new base. This change should have been in 'What's New in 
Python 3.0', though I did not find it.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web