2

According to the doc:

Objects which are instances of user-defined classes are hashable by default; they all compare unequal (except with themselves), and their hash value is their id().

Now from console:

class ABC:
  def __init__(self):
    pass

a = ABC()
id(a)
140102888165648
hash(a)
8756430510353

Shoudln't a have the same hash and id value?

zer0uno
  • 7,521
  • 13
  • 57
  • 86

1 Answers1

3

According to the documentation for __hash__()

User-defined classes have __cmp__() and __hash__() methods by default; with them, all objects compare unequal (except with themselves) and x.__hash__() returns a result derived from id(x).

It seems like the glossary is either outdated or inaccurate.

The documentation for python3's __hash__ is slightly different:

User-defined classes have __eq__() and __hash__() methods by default; with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).

So they even removed the fact that such value should depend on id.

Bakuriu
  • 98,325
  • 22
  • 197
  • 231
  • where did you take that definition? – zer0uno Jun 16 '14 at 18:24
  • Sorry, I was looking in the wrong link. However then I don't understand why in the old glossary the wrote good and in the new glossary the changed.... – zer0uno Jun 16 '14 at 18:28
  • @antox I have added also the python3 documentation, since it seems like the required semantics changed (it doesn't mention `id` at all). – Bakuriu Jun 16 '14 at 18:28
  • @antox Yes, what I'm saying is that the glossary is wrong. It should be updated. They copy-pasted the one for python2.7, when the semantics changed. The real reference is the documentation for `__hash__` which is the one I linked. – Bakuriu Jun 16 '14 at 18:32
  • 1
    @antox I have just opened [an issue](http://bugs.python.org/issue21782) in the python tracker to see if they can fix it. – Bakuriu Jun 16 '14 at 18:37