By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,641 Members | 1,098 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,641 IT Pros & Developers. It's quick & easy.

Python "is" behavior

P: n/a
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?
Jun 27 '08 #1
Share this Question
Share on Google+
4 Replies

P: n/a
On Jun 20, 12:31 pm, michalis.avr...@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
Jun 27 '08 #2

P: n/a
On Jun 20, 9:42*am, George Sakkis <george.sak...@gmail.comwrote:
On Jun 20, 12:31 pm, michalis.avr...@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!
Jun 27 '08 #3

P: n/a
On Jun 20, 12:45 pm, michalis.avr...@gmail.com wrote:
On Jun 20, 9:42 am, George Sakkis <george.sak...@gmail.comwrote:
On Jun 20, 12:31 pm, michalis.avr...@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.

George
Jun 27 '08 #4

P: n/a
For some reason, stacking multiple statements reuses the same object.

Each code object has a co_consts tuple referring to all constants used
in the code. The compiler interns duplicate constants for a single
compiler run, resulting in the same object being used when the code
is put into a single line (or in a function, or module).

When the code is split into multiple interactive statements, the
compiler runs multiple times, and doesn't know anything about past
runs.

Regards,
Martin
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.