diff options
author | Tim Peters <tim.peters@gmail.com> | 2006-05-23 18:45:30 +0000 |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2006-05-23 18:45:30 +0000 |
commit | f31004bc1e8d299f4b1dcb96388ee6e51bef86fb (patch) | |
tree | acea788e0639761451bb0656e1b2a8b0104a2e69 /setup.py | |
parent | 4bbf7f856c9af54230ddda7b35b5e0cd5d2d6b03 (diff) | |
download | cpython-f31004bc1e8d299f4b1dcb96388ee6e51bef86fb.tar.gz |
Bug #1334662 / patch #1335972: int(string, base) wrong answers.
In rare cases of strings specifying true values near sys.maxint,
and oddball bases (not decimal or a power of 2), int(string, base)
could deliver insane answers. This repairs all such problems, and
also speeds string->int significantly. On my box, here are %
speedups for decimal strings of various lengths:
length speedup
------ -------
1 12.4%
2 15.7%
3 20.6%
4 28.1%
5 33.2%
6 37.5%
7 41.9%
8 46.3%
9 51.2%
10 19.5%
11 19.9%
12 23.9%
13 23.7%
14 23.3%
15 24.9%
16 25.3%
17 28.3%
18 27.9%
19 35.7%
Note that the difference between 9 and 10 is the difference between
short and long Python ints on a 32-bit box. The patch doesn't
actually do anything to speed conversion to long: the speedup is
due to detecting "unsigned long" overflow more quickly.
This is a bugfix candidate, but it's a non-trivial patch and it
would be painful to separate the "bug fix" from the "speed up" parts.
Diffstat (limited to 'setup.py')
0 files changed, 0 insertions, 0 deletions