Commit Graph

18 Commits

Author SHA1 Message Date
Florent Xicluna 0762788081 #7092 - Silence more py3k deprecation warnings, using test_support.check_py3k_warnings() helper. 2010-03-21 01:14:24 +00:00
Senthil Kumaran ce8e33a095 Reverting the Revision: 77368. I committed Flox's big patch for tests by
mistake. ( It may come in for sure tough)
2010-01-08 19:04:16 +00:00
Senthil Kumaran 3ddc435af6 Fixing - Issue7026 - RuntimeError: dictionary changed size during iteration. Patch by flox 2010-01-08 18:41:40 +00:00
Nick Coghlan 48361f5cbf Issue 2235: Py3k warnings are now emitted for classes that will no longer inherit a__hash__ implementation from a parent class in Python 3.x. The standard library and test suite have been updated to not emit these warnings. 2008-08-11 15:45:58 +00:00
Neal Norwitz a98e7694ee move test into a unittest.TestCase, no functional changes 2005-11-24 21:58:51 +00:00
Armin Rigo 93677f075d * drop the unreasonable list invariant that ob_item should never come back
to NULL during the lifetime of the object.

* listobject.c nevertheless did not conform to the other invariants,
  either; fixed.

* listobject.c now uses list_clear() as the obvious internal way to clear
  a list, instead of abusing list_ass_slice() for that.  It makes it easier
  to enforce the invariant about ob_item == NULL.

* listsort() sets allocated to -1 during sort; any mutation will set it
  to a value >= 0, so it is a safe way to detect mutation.  A negative
  value for allocated does not cause a problem elsewhere currently.
  test_sort.py has a new test for this fix.

* listsort() leak: if items were added to the list during the sort, AND if
  these items had a __del__ that puts still more stuff into the list,
  then this more stuff (and the PyObject** array to hold them) were
  overridden at the end of listsort() and never released.
2004-07-29 12:40:23 +00:00
Tim Peters 58eb11cf62 Whitespace normalization. 2004-01-18 20:29:55 +00:00
Raymond Hettinger 64958a15d7 Guido grants a Christmas wish:
sorted() becomes a regular function instead of a classmethod.
2003-12-17 20:43:33 +00:00
Michael W. Hudson 9da1efb5ae Remove extra copy of test_key_with_exception that somehow appeared
during a CVS merge.
2003-12-04 11:41:24 +00:00
Michael W. Hudson 1df0f654e8 Fixes and tests for various "holding pointers when arbitrary Python code
can run" bugs as discussed in

[ 848856 ] couple of new list.sort bugs
2003-12-04 11:25:46 +00:00
Raymond Hettinger 37e136373e Make sure the list.sort's decorate step unwinds itself before returning
an exception raised by the key function.
(Suggested by Michael Hudson.)
2003-11-28 21:43:02 +00:00
Raymond Hettinger a690a9967e * Migrate set() and frozenset() from the sandbox.
* 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.
2003-11-16 16:17:49 +00:00
Raymond Hettinger 0a9b9da0c3 Add list.sorted() classmethod. 2003-10-29 06:54:43 +00:00
Raymond Hettinger 42b1ba31af * list.sort() now supports three keyword arguments: cmp, key, and reverse.
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.
2003-10-16 03:41:09 +00:00
Skip Montanaro 4abd5f0fce Allow list sort's comparison function to explicitly be None. See SF patch
661092.
2003-01-02 20:51:08 +00:00
Tim Peters b9099c3df4 SF patch 637176: list.sort crasher
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.
2002-11-12 22:08:10 +00:00
Tim Peters 30e0beab6d Remove cut 'n paste silliness. 2002-08-03 02:17:41 +00:00
Tim Peters 2d8b765cc9 New test for sorting sanity. Note that this will fail in earlier Pythons,
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).
2002-08-01 02:23:06 +00:00