| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
results. It could previously incorrectly return 0 in some cases.
Fixes SF bug 1493322 (pybsddb bug 1184012).
|
| |
|
|
| |
supplied [SF pybsddb bug #1477863]
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
argument. A lot of hair went into supporting that!
|
| |
|
|
| |
decoder. (found by Neal Norwitz)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
46640 Patch #1454481: Make thread stack size runtime tunable.
46647 Markup fix
The first is causing many buildbots to fail test runs, and there
are multiple causes with seemingly no immediate prospects for
repairing them. See python-dev discussion.
Note that a branch can (and should) be created for resolving these
problems, like
svn copy svn+ssh://svn.python.org/python/trunk -r46640 svn+ssh://svn.python.org/python/branches/NEW_BRANCH
followed by merging rev 46647 to the new branch.
|
| |
|
|
| |
(thanks to Neal for review)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to each allocated block. This was using 4 bytes for each such
piece of info regardless of platform. This didn't really matter
before (proof: no bug reports, and the debug-build obmalloc would
have assert-failed if it was ever asked for a chunk of memory
>= 2**32 bytes), since container indices were plain ints. But after
the Py_ssize_t changes, it's at least theoretically possible to
allocate a list or string whose guts exceed 2**32 bytes, and the
PYMALLOC_DEBUG routines would fail then (having only 4 bytes
to record the originally requested size).
Now we use sizeof(size_t) bytes for each of a PYMALLOC_DEBUG
build's extra debugging fields. This won't make any difference
on 32-bit boxes, but will add 16 bytes to each allocation in
a debug build on a 64-bit box.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
the output required more than one line. "Small" dicts got
displayed in seemingly random order (the hash-induced order
produced by dict.__repr__). None of this was documented.
Now pprint functions always sort dicts by key, and the docs
promise it.
This was proposed and agreed to during the PyCon 2006 core
sprint -- I just didn't have time for it before now.
|
| | |
|
| |
|
|
| |
[ 1456209 ] dictresize() vulnerability ( <- backport candidate ).
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Renames functional extension module to _functools and adds a Python
functools module so that utility functions like update_wrapper can be
added easily.
|
| | |
|
| |
|
|
| |
Contributed by Bjorn Tillenius.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
valid and
invalid file paths for the built-in import machinery which leads to
fewer open calls on startup.
Also fix issue with PEP 302 style import hooks which lead to more open()
calls than necessary.
|
| | |
|
| |
|
|
|
|
|
|
| |
QueryPerformanceCounter(), but we believe Win64 does
support it now. So use in time.clock().
It would be peachy if someone with a Win64 box tried
this ;-)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
``long(str, base)`` is now up to 6x faster for non-power-of-2 bases. The
largest speedup is for inputs with about 1000 decimal digits. Conversion
from non-power-of-2 bases remains quadratic-time in the number of input
digits (it was and remains linear-time for bases 2, 4, 8, 16 and 32).
Speedups at various lengths for decimal inputs, comparing 2.4.3 with
current trunk. Note that it's actually a bit slower for 1-digit strings:
len speedup
---- -------
1 -4.5%
2 4.6%
3 8.3%
4 12.7%
5 16.9%
6 28.6%
7 35.5%
8 44.3%
9 46.6%
10 55.3%
11 65.7%
12 77.7%
13 73.4%
14 75.3%
15 85.2%
16 103.0%
17 95.1%
18 112.8%
19 117.9%
20 128.3%
30 174.5%
40 209.3%
50 236.3%
60 254.3%
70 262.9%
80 295.8%
90 297.3%
100 324.5%
200 374.6%
300 403.1%
400 391.1%
500 388.7%
600 440.6%
700 468.7%
800 498.0%
900 507.2%
1000 501.2%
2000 450.2%
3000 463.2%
4000 452.5%
5000 440.6%
6000 439.6%
7000 424.8%
8000 418.1%
9000 417.7%
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
"base" parameter.
|
| |
|
|
|
|
| |
Applied patch zombie-frames-2.diff from sf patch 876206 with updates for
Python 2.5 and also modified to retain the free_list to avoid the 67%
slow-down in pybench recursion test. 5% speed up in function call pybench.
|
| | |
|
| |
|
|
| |
I suppose this could be backported if anyone cares.
|
| |
|
|
|
| |
strings and removes a possible "U" before passing the mode to the
C library function.
|
| | |
|
| |
|
|
| |
and several features added, such as speed and geometry control.
|
| | |
|
| | |
|
| |
|
|
| |
copy() method.
|
| | |
|
