1

The Python documentation for the id() function says

id(object) Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.

So, practically, it guaranties the uniqueness as an hash function, but only within the object lifespan and without the cool thing that an hash is hardly reconstructable.

Why should one use id()?

Nisba
  • 3,210
  • 2
  • 27
  • 46
  • 3
    One reason: "Numeric values that compare equal have the same hash value (even if they are of different types, as is the case for 1 and 1.0)." That's not the case for id(). – Brad Solomon Apr 06 '18 at 15:26
  • 2
    Because you want an integer which is guaranteed to be unique and constant for this object during its lifetime? – Aran-Fey Apr 06 '18 at 15:28

2 Answers2

5

hash is equal for equal objects, and may be equal even for unequal objects. hash doesn't even exist for mutable objects.

id is guaranteed to be unique for an object during its lifetime, and it doesn't care about mutation.

The use cases are completely different.

>>> x, y, z = 1, 1.0, [1]
>>> hash(x), hash(y)
(1, 1)
>>> hash(z)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> id(x), id(y)
(10832608, 139668416746072)
>>> id(z)
139668282136008
>>> z.append(2)
>>> id(z)
139668282136008
>>> hash(-1), hash(-2)
(-2, -2)
user2357112
  • 260,549
  • 28
  • 431
  • 505
  • anyway, `id(str(1)) == id(str(1))` is true! – Nisba Apr 06 '18 at 15:30
  • 2
    @Nisba, yes, that's an implementation detail / optimization, true because `1` is automatically interned, so there's only one instance of it. – Charles Duffy Apr 06 '18 at 15:31
  • @Nisba: That's because Python happens to reuse the same object. Don't use `id` or `is` on immutable primitives; doing so is basically useless. – user2357112 Apr 06 '18 at 15:31
  • It does't take too much work to get distinct `str` objects: `x = "12"; y = x[0] + x[1]` was sufficient in one test. – chepner Apr 06 '18 at 15:34
  • @user2357112 please see the edit I am going to write – Nisba Apr 06 '18 at 15:34
  • @Nisba: If you're about to change your question to ask more things it didn't ask previously, don't. – user2357112 Apr 06 '18 at 15:34
  • ...on which point, see [What to do when someone answers: Don't be a chameleon, don't be a vandal](https://meta.stackoverflow.com/questions/332820/what-to-do-when-someone-answers-dont-be-a-chameleon-dont-be-a-vandal) -- the former being immediately relevant. – Charles Duffy Apr 06 '18 at 15:35
  • @chepner but `id("12") == id("1"+"2")` is True – Nisba Apr 06 '18 at 15:36
  • @user2357112 ok. I defined an empty class and two different instances have the same ids, even if now it is not a primitive – Nisba Apr 06 '18 at 15:37
  • @Nisba, yup -- that's something a peephole optimizer can do in the bytecode ahead-of-time, but like all implementation-defined optimizations, it's unsafe to rely on either presence or lack thereof. – Charles Duffy Apr 06 '18 at 15:37
  • 1
    @Nisba: [*During its lifetime.*](https://stackoverflow.com/questions/3877230/why-does-id-id-and-id-id-in-cpython) – user2357112 Apr 06 '18 at 15:37
  • 2
    @Nisba Yes, which is why I specifically used `x[0] + x[1]` in my example. CPython can optimize literals more than it can object references. Also, even for longer strings, the literals passed to `id` are anonymous and the temporary object can be reclaimed after the call to `id` completes, allowing the object id to be reused for the second one. – chepner Apr 06 '18 at 15:37
1

You can think of the id function in python like a sort of pointer, it is a unique number for the that object. so two identical objects can have the same hash, but different ids (unless the hash is reference based, in which case it isn't guaranteed to return the same hash on different processes)

check this answer out as well What is the id( ) function used for?

Daniel Dror
  • 2,304
  • 28
  • 30
  • I think pointers and id are very different concepts, except for CPython – Nisba Apr 06 '18 at 15:33
  • I am aware of that, I will update my answer to clarify, but in a sense, it is the representation of an instance, just as a pointer is. – Daniel Dror Apr 06 '18 at 15:35