Python "is" behavior

[Jean-Paul Calderone]

On Fri, 20 Jun 2008 10:07:56 -0700 (PDT), George Sakkis <george.sakkis at gmail.com> wrote:
>On Jun 20, 12:45 pm, michalis.avr... at gmail.com wrote:
>> On Jun 20, 9:42 am, George Sakkis <george.sak... at gmail.com> wrote:
>>
>>
>>
>> > On Jun 20, 12:31 pm, michalis.avr... at gmail.com wrote:
>>
>> > > I am not certain why this is the case, but...
>>
>> > > >>> a = 256
>> > > >>> b = 256
>> > > >>> a is b
>>
>> > > True
>>
>> > > >>> a = 257
>> > > >>> b = 257
>> > > >>> a is b
>>
>> > > False
>>
>> > > Can anyone explain this further? Why does it happen? 8-bit integer
>> > > differences?
>>
>> > No, implementation-dependent optimization (caching). For all we know,
>> > the next python version may cache up to 1024 or it may turn off
>> > caching completely; do not rely on it. More generally, do not use 'is'
>> > when you really mean '=='.
>>
>> > George
>>
>> Thank you George. I am very curious about some of these internal
>> Python things that I keep stumbling upon through friends. And thank
>> you for all the help!
>
>As far it's plain curiosity it's ok, but it's a small implementation
>detail you shouldn't rely on. There's nothing magic about 256, just
>the size decided for 2.5. If you tried it on 2.4 you'd get:
>
>Python 2.4.2 (#1, Mar  8 2006, 13:24:00)
>[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
>>>> a=99
>>>> b=99
>>>> a is b
>True
>>>> a=100
>>>> b=100
>>>> a is b
>False
>
>I was more surprised by the following:
>
>Python 2.5.1 (r251:54863, May  8 2007, 14:46:30)
>[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
>>>> a= 123456; b=123456; a is b
>True
>
>For some reason, stacking multiple statements reuses the same object.
>

This is because using the ";" puts the statements into the same compilation
unit as each other.  So secretly an integer object is created for 123456
and then a and b are both given a reference to it.  This is a different
mechanism than the other case, where the builtin integer cache causes the
literal 100 to refer to the same object each time it is evaluated.

Jean-Paul