According to my and Larry's measurements [1] the distribution of created int's by size during running Python tests is:

On 32-bit Linux:
int                               42828741  13.40%
                              0     425353   0.99%   0.99%
                              1   21399290  49.96%  50.96%
                              2   10496856  24.51%  75.47%
                              3    4873346  11.38%  86.85%
                              4    1021563   2.39%  89.23%
                              5    1246444   2.91%  92.14%
                              6     733676   1.71%  93.85%
                              7     123074   0.29%  94.14%
                              8     139203   0.33%  94.47%
...

On 64-bit Linux:
int                              47600237  13.53%
                             0     294964   0.62%   0.62%
                             1   36135772  75.92%  76.53%
                             2    4504046   9.46%  86.00%
                             3    2109837   4.43%  90.43%
                             4    1277995   2.68%  93.11%
                             5     542775   1.14%  94.25%
                             6     485451   1.02%  95.27%
...

86% of ints have size <= 3 on 32-bit and <= 2 on 64-bit. This is enough to represent 32-bit integers (as in Python 2 int). I think we should support free list not only for 1-digit ints, but at least up to 3 digit on 32-bit build and up to 2 digits on 64-bit build. Other natural limit is 3 digit on 64-bit build (enough to represent 64-bit C long on Linux or pointer on all platforms). Larger integers perhaps are encountered mainly in tests.

Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL.