1

Searching, I noticed that the id() function returns an integer and that guarantees be unique and constant for the object.

When comparing two different objects getting results, which may have allowed these different results ??

I saw an example in an ebook that comparison id(Car()) == id (Car()) returns False but when running the same code returned True

class Car.py

class Car:
    pass

Code in Idle

>>> from Car import Car
>>> ferrari = Car()
>>> lamborghini = Car()
>>> id(lamborghini) == id(ferrari)
False
>>> id(Car()) == id(Car())
True

https://docs.python.org/3/library/functions.html#id

Oliveira
  • 129
  • 7
  • Whether or not `id(object()) == id(object())` or not is not really a Python question. It depends on the implementation and whether it a) immediately destroys unneeded objects and b) reuses the last space freed for the next object. At least some versions of CPython do this for at least some object classes. The main use of id() is to test details of an implementation. – Terry Jan Reedy Oct 26 '16 at 19:17

3 Answers3

1

If you are wondering why id(ferrari) == id(lamborghini) is false but id(Car()) == id(Car()) is true. This is because when you say ferrari = Car(), Python generates a new object based on Car structure. So ferrari is a new object with unique id only to ferrari.

In id(Car()) == id(Car()) the true evaluation comes from the fact that Car objects don't live outside of the id() call.

I hope this helps!

Steven Rumbalski
  • 44,786
  • 9
  • 89
  • 119
Chris Brisson
  • 300
  • 1
  • 11
  • You are ignoring the second part of the question, which is why does `id(Car()) == id(Car())` evaluate to `True`? – Steven Rumbalski Oct 25 '16 at 15:22
  • `id(Car()) == id(Car())` both refer to the same Car class. If I had a piece of paper with instructions, it will always be the same piece to paper each time I point to it. But if I used those paper instructions to make 2 cars. They would be different objects, even though they were made using the same piece of paper with instructions. – Chris Brisson Oct 25 '16 at 15:34
  • Wrong. `Car()` is an object created from the `Car` class. For the correct explanation see my answer. – Steven Rumbalski Oct 25 '16 at 15:39
  • 2
    Just to add on a little more. In this statement `id(Car()) == id(Car())` two `Car` objects are created. They do not need to be assigned to any names to exist as objects. Your explanation would be correct if the code had been `id(Car) == id(Car)` but it was `id(Car()) == id(Car())`. – Steven Rumbalski Oct 25 '16 at 15:46
  • 1
    Shoot, you're right, I added that comment too quickly. Car() instantiates a Car object and so the true evaluation comes from the fact that they don't live outside of the `id()` call. – Chris Brisson Oct 25 '16 at 15:55
  • 1
    "Car() instantiates a Car object and so the true evaluation comes from the fact that they don't live outside of the id() call." A very succinct summary. Add that info to your answer and I'll change my downvote to an upvote. – Steven Rumbalski Oct 25 '16 at 16:02
1

The id of any object is supposed to be unique so it seems that id(Car()) == id(Car()) should be False, but it is evaluating to True. However, the id of an object is only guaranteed to be unique during that object's lifetime. Since these Car objects are transitory they only last long enough to be passed to id() and then they are garbage collected. Python is evaluating one side of the ==, garbage collecting, and then evaluating the other side. In the process the id gets reused for each Car() object.

For a longer explanation see abarnert's answer to Why is the id of a Python class not unique when called quickly?

Community
  • 1
  • 1
Steven Rumbalski
  • 44,786
  • 9
  • 89
  • 119
0

From the Documentation:

id(object): Return the “identity” of an object. This is an integer (or long integer) which is guaranteed to be unique and constant for this object during its lifetime.

You are creating two distinct instances of the class Car, namely ferrari and lamborghini, therefore their identifiers are different.