Object Value vs Object Identity

Everything in Python is an object—is a variable an object? I know that it points to an assigned value which is an object, but is it an object?

Hehe, philosophical! No, a variable is a reference to an object, not an object itself. Like the shadows on Plato’s cave wall 😜…

I suspected as much, but your statement is “everything in Python is an object.” A variable is a thing. Picky, picky, picky. BTW, I didn’t know there were shadows on Plato’s cave wall. Are you sure? Maybe at the entrance. :-)

Almost. A variable is a reference to a thing. A variable itself doesn’t have a memory location (it’s not “a thing”) but only points to a thing (=an object).

Maybe we could agree on “Everything in Python that has a memory location is an object”–but I think that does sound less catchy!

There are shadows in Plato’s cave–but I don’t think the allegory to variables and objects holds that well apart from that.

Hi I’m a bit confused with the example . My understanding has always been that all variables that reference the same value will have the same id. i.e if n =300 and m=300 then id(n) == id(m) will be True.

pls ignore my last comment guys

I am bit confused, Need help! if two object ids are different in memory , but has the same Object VALUE shouldnt objects ids be different right?

For example : n = 300 m = 300 # object ids are different , yet the object value is the same print(id(n)) print(id(m))

In your videos when you ran code the object ids were different ,

but when I use your example an ran code the object ids were the exact same , why is that? I dont get it my example: n = 300 m = 300 print(id(n)) print(id(m))

also when I compare both object ids the answer came back TRUE instead of false ? Confused ? Can anybody help me!:/

In referring to my last comment objects ids keep popping up the same 1887265792816 1887265792816

It might be related to your Python version @kingjay2498. Make sure to check the excellent comments in the upcoming video section. Hope that helps to shed some light on your particular situation.

Hi Team, I was trying same example in my interpreter and got below different outputs:

ipython

In [1]: n = 300

In [2]: m = 400

In [3]: id(n)
Out[3]: 83420736

In [4]: id(m)
Out[4]: 83420912

In [5]: n = 300

In [6]: m = 300

In [7]: id(n)
Out[7]: 83420928

In [8]: id(m)
Out[8]: 83420768

User editor thonny

n = 300
m = 400
# id tells where object lives in memory
print (f"id of n {id(n)}")
print (f"id of m {id(m)}")
n = 300
m = 300
# id tells where object lives in memory
print (f"id of n {id(n)}")
print (f"id of m {id(m)}")

Output id of n 69962880 id of m 69963760 id of n 69962880 id of m 69962880

Now little confused that when i used ipython interpreter for different address for variable of same value and in editor got same value.

In [16]: a = 2

In [17]: b = 2

In [18]: id(a)
Out[18]: 8791518529216

In [19]: id(b)
Out[19]: 8791518529216

In [20]: a = 300

In [21]: b = 300

In [22]: id(a)
Out[22]: 84490864

In [23]: id(b)
Out[23]: 84489456

Why?

@manupanduworld just keep watching to the next video: realpython.com/lessons/small-integer-caching/ :)

Martin, not to disagree with you or Plato :-) … But the names/variables are indeed objects as well. If you use the dir() function it will return a list of names/variables in the local namespace, i.e. ['n', 'm', ...]

So, you actually have a “string object” pointing to an “integer object”. And each having a memory location as well. So, in Python everything truly is an object. :-)

As for Plato, the shadows on the cave walls are objects too and not simply references. You know, class Shadow() is composed of photons which in turn simply hit Plato’s eyeballs, LOL

Following up on Alain Rouleau, isn’t a variable a key in the globals() dictionary?

>>> my_string = 'hello'

>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <_frozen_importlib_external.SourceFileLoader object at 0x110caac88>, '__spec__': None, '__annotations__': {}, '__builtins__': <module 'builtins' (built-in)>, '__cached__': None, 'my_string': 'hello'}

>>> globals()['my_string']
'hello'

I’m not sure how this relates to the issue of names/variables as references to memory addresses, however.

There are a few built-in functions in Python that let you get a dictionary of variables:

• globals()
• locals()
• vars()
• dir()

As the name implies, calling globals() will only return the global variables. (It’ll skip variables defined in a function, for example.)

Regarding variables in Python, you can think of them as labels attached to objects. They’re like yellow stickers with names written on them, but apart from that, don’t have any type, value, or identity. These are attributes of a particular object a variable is pointing to, which can change over time. That isn’t true for other languages, where variables are more like cardboard boxes with a predefined shape and size.

Hey there. Playing with the memory assingments. Here’s my code which when run:

m  = 100
n = m
print(id(n), id(m))  # print call 1

m = 400
print(id(n), id(m))  # print call 2

m = 'test'
print(id(n), id(m))  # print call 3

m = 400
(print(id(n), id(m)))  # print call 4

Produces the following output:

2961643492816 2961643492816 # same memory address, since n = m -> both refer to the same object
2961643492816 2961646790640 # diff. memory addresses, obviously
2961643492816 2961646716144 # reassignment, diff. memory addresses, logical
2961643492816 2961646790640 # the memory address of `m` becomes again the same as in the 2nd id() call. 

The above situation (see print calls 2 and 4) appears odd to me, since even though the object whose value was 400 (the variable m) was abandoned as a result of the reassignment m = 'test', its old memory address surfaced up in the last reassignment. This is despite the fact that the object 400 clearly wasn’t reachable until the reassignment (see the print call 4).

When I learned JS (sorry for bringing it in) the teaching was that those objects which can’t be reached are removed automatically from the memory as a result of the garbage collection process performed by the JS engine.

I haven’t checked the JS behaviour with the same code yet, but it seems that there are other conditions for an object to be collected as garbage than the mere fact that it can’t be reached.

Any comments on this?

@DoubleA According to the documentation, id() returns the object’s identity. Returning a memory address is a CPython implementation detail, which shouldn’t be relied upon.

In your case, it must have been a coincidence that the same piece of memory got reused for a different object. I couldn’t reproduce this behavior on my computer, which may very well depend on a specific Python interpreter build or even the operating system.

By the way, I just noticed you are assigning the same numerical literal, which may trigger another quirk of CPython called interning.