| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
sorted() becomes a regular function instead of a classmethod.
|
|
|
|
| |
during a CVS merge.
|
|
|
|
|
|
| |
can run" bugs as discussed in
[ 848856 ] couple of new list.sort bugs
|
|
|
|
|
| |
an exception raised by the key function.
(Suggested by Michael Hudson.)
|
|
|
|
|
|
|
|
| |
* Install the unittests, docs, newsitem, include file, and makefile update.
* Exercise the new functions whereever sets.py was being used.
Includes the docs for libfuncs.tex. Separate docs for the types are
forthcoming.
|
| |
|
|
|
|
|
|
|
| |
key provides C support for the decorate-sort-undecorate pattern.
reverse provide a stable sort of the list with the comparisions reversed.
* Amended the docs to guarantee sort stability.
|
|
|
|
| |
661092.
|
|
|
|
|
|
|
|
|
|
|
| |
Armin Rigo's Draconian but effective fix for
SF bug 453523: list.sort crasher
slightly fiddled to catch more cases of list mutation. The dreaded
internal "immutable list type" is gone! OTOH, if you look at a list
*while* it's being sorted now, it will appear to be empty. Better
than a core dump.
|
| |
|
|
in the stability tests.
Bizarre: this takes 11x longer to run if and only if test_longexp is
run before it, on my box. The bigger REPS is in test_longexp, the
slower this gets. What happens on your box? It's not gc on my box
(which is good, because gc isn't a plausible candidate here).
The slowdown is massive in the parts of test_sort that implicitly
invoke a new-style class's __lt__ or __cmp__ methods. If I boost
REPS large enough in test_longexp, even the test_sort tests on an array
of size 64 visibly c-r-a-w-l. The relative slowdown is even worse in
a debug build. And if I reduce REPS in test_longexp, the slowdown in
test_sort goes away.
test_longexp does do horrid things to Win98's management of user
address space, but I thought I had made that a whole lot better a month
or so ago (by overallocating aggressively in the parser).
|