Object Value vs Object Identity

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.