[Tutor] Integer ID Caching

Kent Johnson kent37 at tds.net
Tue Sep 4 15:25:17 CEST 2007


wormwood_3 wrote:
> I came across the topic of internal Python IDs recently, and learned that the internal numeric ids of small integers are cached to increase speed. I had read that as of 2.5, this applied to integers between -1 and 100. However, doing some quick tests, this seems not to be accurate:
> 
> Python 2.5.1 (r251:54863, May  2 2007, 16:56:35) 
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> a = 10
>>>> b = 10
>>>> print id(a), id(b)
> 135716556 135716556
>>>> c = 250
>>>> d = 250
>>>> print id(c), id(d)
> 135719604 135719604
>>>> e = 300
>>>> f = 300
>>>> print id(e), id(f)
> 135718812 135718824
> 
> So the upper end of the interning range appears to be between 250 and 300, not 100.
> 
> Does anyone know the exact number, 

 From Python-2.5.1/Objects/intobject.c:

#ifndef NSMALLPOSINTS
#define NSMALLPOSINTS		257
#endif
#ifndef NSMALLNEGINTS
#define NSMALLNEGINTS		5
#endif
#if NSMALLNEGINTS + NSMALLPOSINTS > 0
/* References to small integers are saved in this array so that they
    can be shared.
    The integers that are saved are those in the range
    -NSMALLNEGINTS (inclusive) to NSMALLPOSINTS (not inclusive).
*/

> when it changed, 

Python 2.4.1 has
#ifndef NSMALLPOSINTS
#define NSMALLPOSINTS		100

Here is the actual changeset:
http://svn.python.org/view?rev=42552&view=rev

which references this RFE which includes the reason for the change:
http://bugs.python.org/issue1436243

and if a decision has been made for future changes?

I doubt it, it will change in response to some unanticipated future 
requirement, just as it did in this case.

Kent


More information about the Tutor mailing list