2

Here's my snippet of code

  >>> a = "some_string"
  140420665652016
  >>> id(a)
  >>> id("some" + "_" + "string")
  140420665652016

Notice that both the ids are same. But this does not happen with integers (which are also immutable like strings).

>>> a = 999
>>> id(a)
140420666022800
>>> id(999)
140420666021200
>>> id(998 + 1)
140420666023504

I'm not able to find a reason of why it's happening only with strings.

Satwik
  • 1,281
  • 4
  • 18
  • 31
  • 3
    That's a CPython thing. Small strings like small integers (the ones you've shown are large) are interned for performance reasons. Looking for the relevant link... – Moses Koledoye Aug 30 '17 at 13:47
  • 1
    The last paragraph of ["Objects, values and types"](https://docs.python.org/3/reference/datamodel.html#objects-values-and-types) explains this: "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed.". See also the linked duplicate. If that doesn't solve your question please explain "why it doesn't solve your question" and (optionally) ping me. – MSeifert Aug 30 '17 at 13:51
  • @Satwick add spaces, exclamation marks or accented characters to your strings and you'll have a different behaviour. Also try the int test with small ints and you'll find out they behave the same as your string example. To make a long story short: CPython caches some strings (those who are valid python identifiers actually) and "small" integers (for a definition of "small" that changes from version to version) for performance reasons. – bruno desthuilliers Aug 30 '17 at 13:53
  • Oh I see, I just came to know that the integers from -1 to 256 are also cached. So if I correctly understand this, it is an CPython optimization that tries to use existing immutable objects in some cases (implementation specific) rather than creating a new object every time. – Satwik Aug 30 '17 at 13:58

0 Answers0