On Fri, 20 Jun 2008 10:07:56 -0700 (PDT), George Sakkis <[EMAIL PROTECTED]>
wrote:
On Jun 20, 12:45 pm, [EMAIL PROTECTED] wrote:
On Jun 20, 9:42 am, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Jun 20, 12:31 pm, [EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
