The sunday tip #1: Python cached integers

by Davide Mastromatteo
2 minute read

https://imgs.xkcd.com/comics/compiling.png

Hey guys, today's post is just a small tip that inaugurate a new series: the sunday tips. In this series I will give you a Python tip each sunday so to whet your pythonic appetite before starting a new working week. Let me know if you like the idea in the comment below or maybe buying me a coffee so to tip my sunday tip! :)

This week tip is about…

Python integer cache.

Let's start with an example, open your REPL and try this:

1>>> a = 666
2>>> b = 666
3>>> a is b
4>>> False

As you can see we have assigned the value 666 to the variable a and then the value 666 to the variable b. Unsurprisingly, the two variables are pointing to two different objects.

So, what's strange with that?

Well… nothing… unless the interpreter doesn't behave differently depending on the number we assign… Let's try with this second example:

1>>> a = 3
2>>> b = 3
3>>> a is b
4>>> True

What? Why the two variables a and b are now pointing to the same obejct?

No, you Python interpreter is not religious, it doesn't consider the number 3 better or worse than the number 666, it just cache the values between -5 and 256 for performance reasons.

That's cool uh?

Yes, but this is what I get with the REPL, would it be the same with the compiler? Well, apparently the compiler behave in a different way and analyzing your script, it may decide to cache also different numbers:

 1a = 3
 2b = 3
 3c = 666
 4d = 666
 5e = 5.5
 6f = 5.5
 7g = 11 / 2
 8
 9print (a is b)
10print (c is d)
11print (e is f)
12print (f is g)

And running this example you will get:

1True
2True
3True
4False

So, what have we learned?

  • your compiler does optimize more than you think

  • what you get in the REPL is not always identical to what you get from the compiler

  • even float numbers may be cached

  • not every number is cached ;)

Happy sunday!

D


Did you find this article helpful?