1

While analyzing id() built-in behavior with numbers & string I got confusion.

x = 100
y = x   # x and y both points to same object that is 100
id(x)
162569156
id(y)
162569156

Now I tried to change the object where x is pointing as

 x = 200 # since x points to different objects & garbage collector increments reference counts as its no longer points to old objects 
 id(y)
 162569156
 id(x)   # its different 
 162569932

Now as of my understanding python garbage collector which is reference count garbage collector, the moment x=200 or number of references changes, it clean it up. Here is my doubt, from above point can I assume that whenever I will do x = 100 again i.e tried to point to old object, id() will give exactly same memory location always as previuosly ?

x = 100 #making x to points to same old object
id(x)
162569156  #getting same old location
id(y)
162569156

If above is true then does that means that for each number(millions) one references will be there and id() gives same location when points to old object in future ?

I got this doubt as in other language like in C once pointer lost its address(heap), its not guaranteed that next time it will get same address when you will do malloc.

user3942918
  • 25,539
  • 11
  • 55
  • 67
Achal
  • 11,821
  • 2
  • 15
  • 37
  • 5
    Python doesn't guarantee that. You're just getting confused because 1) `100` is small enough that it's permanently in the (implementation detail) small integer cache, and 2) you're putting too much faith in extrapolation from experiment. – user2357112 Apr 12 '18 at 04:17
  • Okay. Then how python differentiate or maintain reference count for Small and bigger objects. – Achal Apr 12 '18 at 04:20
  • @user2357112 I mean when `x` points to different object, what garbage collector do is its looks at no of references, my doubt how `id()` returns _same memory location_ if its _small_ or _different_ if its _bigger_ ? Does _id()_ do all these stuff like calculating length or _garbage collector_ having other entries to take care of these. – Achal Apr 12 '18 at 04:47
  • 1
    When you try to create a new integer object, it tests the value to see if it will be in the small integer cache, and if so it just assigns that preexisting object. There's no need for reference counting on those cache objects since they can never be destroyed. All of this is implementation details that are subject to change and don't materially affect the operation of any program. – Mark Ransom Apr 12 '18 at 04:47
  • Thanks for nice explanation @MarkRansom So does it means that for all cache objects(smaller one,how it differentiate still not clear to me) python doesn't keep track of references at all. – Achal Apr 12 '18 at 05:07
  • How to see the implementation of garbage collector i.e `entries/information` its contains ? Like I can see the linux `process` info in `struct task_struct` similarly in python ? – Achal Apr 12 '18 at 05:21
  • Actually I don't know if Python tracks references for its cached objects or not. It might still do so just to remain consistent with all other Python objects; bumping the reference count to keep it from reaching zero would prevent the cached objects from being destroyed. – Mark Ransom Apr 12 '18 at 12:38

1 Answers1

-1

for small values python always create one id and store the ones created when the same value created simply assign that id to variable

Python caches integers in the range [-5, 256], so it is expected that integers in that range are also identical.

In [1]: x=100

In [2]: y=100 #here x and y are diff but still same id

In [3]: id(x)
Out[3]: 10758048

In [4]: id(y)
Out[4]: 10758048

i just wanted to show some demo for large ints

In [9]: x=1000

In [10]: x=y

In [11]: id(x)
Out[11]: 20359984

In [12]: id(y)
Out[12]: 20359984

In [13]: x=1001

In [14]: id(x)
Out[14]: 20360056

In [15]: x=1000 # again assigning to x to 1000

In [16]: id(x)
Out[16]: 19649168 # id got differs because python normally does not keep reference for large ints

Similar Question

Roushan
  • 4,074
  • 3
  • 21
  • 38