[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