-3

I am trying to study assignment in python I was confused by this.

>>> a=343434;b=343434
>>> a is b
True
>>> a=343434
>>> b=343434
>>> a is b
False
Abhishek Bhatia
  • 9,404
  • 26
  • 87
  • 142
  • 2
    Are you sure about the first one? I get False in both – elelias May 22 '16 at 17:50
  • I got the same result as you, then googled it and got this link: http://stackoverflow.com/questions/2988017/string-comparison-in-python-is-vs – trinaldi May 22 '16 at 17:50
  • 2
    @elelias I got different results in Python 2.7 and Python 3.5. – Vedang Mehta May 22 '16 at 17:53
  • Lol, my Python 3.2.5 (v3.2.5:cef745775b65) segfaults when I try to do `a is b` :( – ForceBru May 22 '16 at 18:00
  • That you assign the both variables on the same line is duplicate of the `257 is 257`. – Antti Haapala -- Слава Україні May 22 '16 at 18:17
  • 4
    Related: [Different behavior in python script and python idle?](http://stackoverflow.com/questions/31260988/different-behavior-in-python-script-and-python-idle) – Basically, code inserted at once in an interpreter session input is handled just like a full script file, so all optimizations (constant literal reuse) applies. – poke May 22 '16 at 18:20
  • @AnttiHaapala If you read forward it mentions, `literal numbers compare properly`. This is different though same in concept. It is easy to get confused by this. – Abhishek Bhatia May 22 '16 at 18:25
  • @poke What do mean by constant literal reuse? Is this limited to integers or the same goes with other immutable values also. – Abhishek Bhatia May 22 '16 at 18:28
  • @AbhishekBhatia Of course this only works with immutable objects (otherwise a script using `a = []` and `b = []` would share changes in both objects). I don’t know the specifics of this optimization though, but it is applying to integers, floats and strings at least. – poke May 22 '16 at 18:37
  • @poke yeah, if possible can you please provide a reference that it works the same way with other immutables like strings and float. – Abhishek Bhatia May 22 '16 at 20:31
  • @AbhishekBhatia No, I won’t, you can easily test that yourself if you need “proof”. In any way, two separate literals being the same object is an implementation detail at best, so you shouldn’t rely on it ever anyway. Test equality using `==`. – poke May 22 '16 at 20:35
  • @poke Yeah, I am just trying to understand `is`'s behavior. I had tested it, it seems there is more to `strings` at least, thus asked for reference. :) `>>> a='asdf' >>> b='asdf' >>> a is b True >>> a='a s' >>> b='a s' >>> a is b False` – Abhishek Bhatia May 22 '16 at 20:39
  • @AbhishekBhatia That’s due to [string interning](http://stackoverflow.com/questions/15541404/python-string-interning), which is also an implementation detail. – poke May 22 '16 at 20:43

1 Answers1

6

The Python interpreter is smart. In the first line, it can see the definition of both a and b and the assignment at the same time, so it 'thinks': "man, I can make them point to the same location to save memory", and so it does. It can optimize your code for memory usage.

In the second case, it allocates memory as soon as it sees the definitions. It 'thinks': "hey, I've got a definition here! Let me allocate some memory!", and so it does. It cannot optimize your code for memory usage here.

That's why these objects are not the same.

This works only in 'live mode' (when you're inserting commands into the interpreter and it deals with them right away). If you put

a=343434
b=343434
print a is b

into a file (say, test.py) and then run python test.py, it will output True (at least in Python 2.7.10), because, as in the first case, it can see the whole code at once and perform some optimizations.

ForceBru
  • 43,482
  • 10
  • 63
  • 98