summaryrefslogtreecommitdiffstats
path: root/Lib/test/test_sort.py
Commit message (Collapse)AuthorAgeFilesLines
* Whitespace normalization.Tim Peters2004-01-181-2/+0
|
* Guido grants a Christmas wish:Raymond Hettinger2003-12-171-55/+0
| | | | sorted() becomes a regular function instead of a classmethod.
* Remove extra copy of test_key_with_exception that somehow appearedMichael W. Hudson2003-12-041-7/+0
| | | | during a CVS merge.
* Fixes and tests for various "holding pointers when arbitrary Python codeMichael W. Hudson2003-12-041-0/+45
| | | | | | can run" bugs as discussed in [ 848856 ] couple of new list.sort bugs
* Make sure the list.sort's decorate step unwinds itself before returningRaymond Hettinger2003-11-281-0/+7
| | | | | an exception raised by the key function. (Suggested by Michael Hudson.)
* * Migrate set() and frozenset() from the sandbox.Raymond Hettinger2003-11-161-2/+1
| | | | | | | | * 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.
* Add list.sorted() classmethod.Raymond Hettinger2003-10-291-0/+58
|
* * list.sort() now supports three keyword arguments: cmp, key, and reverse.Raymond Hettinger2003-10-161-45/+101
| | | | | | | 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.
* Allow list sort's comparison function to explicitly be None. See SF patchSkip Montanaro2003-01-021-0/+20
| | | | 661092.
* SF patch 637176: list.sort crasherTim Peters2002-11-121-0/+29
| | | | | | | | | | | 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.
* Remove cut 'n paste silliness.Tim Peters2002-08-031-2/+0
|
* New test for sorting sanity. Note that this will fail in earlier Pythons,Tim Peters2002-08-011-0/+124
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).