Commit Graph

14 Commits

Author SHA1 Message Date
Guido van Rossum 805365ee39 Merged revisions 55007-55179 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/p3yk

........
  r55077 | guido.van.rossum | 2007-05-02 11:54:37 -0700 (Wed, 02 May 2007) | 2 lines

  Use the new print syntax, at least.
........
  r55142 | fred.drake | 2007-05-04 21:27:30 -0700 (Fri, 04 May 2007) | 1 line

  remove old cruftiness
........
  r55143 | fred.drake | 2007-05-04 21:52:16 -0700 (Fri, 04 May 2007) | 1 line

  make this work with the new Python
........
  r55162 | neal.norwitz | 2007-05-06 22:29:18 -0700 (Sun, 06 May 2007) | 1 line

  Get asdl code gen working with Python 2.3.  Should continue to work with 3.0
........
  r55164 | neal.norwitz | 2007-05-07 00:00:38 -0700 (Mon, 07 May 2007) | 1 line

  Verify checkins to p3yk (sic) branch go to 3000 list.
........
  r55166 | neal.norwitz | 2007-05-07 00:12:35 -0700 (Mon, 07 May 2007) | 1 line

  Fix this test so it runs again by importing warnings_test properly.
........
  r55167 | neal.norwitz | 2007-05-07 01:03:22 -0700 (Mon, 07 May 2007) | 8 lines

  So long xrange.  range() now supports values that are outside
  -sys.maxint to sys.maxint.  floats raise a TypeError.

  This has been sitting for a long time.  It probably has some problems and
  needs cleanup.  Objects/rangeobject.c now uses 4-space indents since
  it is almost completely new.
........
  r55171 | guido.van.rossum | 2007-05-07 10:21:26 -0700 (Mon, 07 May 2007) | 4 lines

  Fix two tests that were previously depending on significant spaces
  at the end of a line (and before that on Python 2.x print behavior
  that has no exact equivalent in 3.0).
........
2007-05-07 22:24:25 +00:00
Guido van Rossum be19ed77dd Fix most trivially-findable print statements.
There's one major and one minor category still unfixed:
doctests are the major category (and I hope to be able to augment the
refactoring tool to refactor bona fide doctests soon);
other code generating print statements in strings is the minor category.

(Oh, and I don't know if the compiler package works.)
2007-02-09 05:37:30 +00:00
Guido van Rossum b940e113bf SF patch 1631942 by Collin Winter:
(a) "except E, V" -> "except E as V"
(b) V is now limited to a simple name (local variable)
(c) V is now deleted at the end of the except block
2007-01-10 16:19:56 +00:00
Tim Peters d5f4359458 New test %sort. This takes a sorted list, picks 1% of the list positions
at random, and replaces the elements at those positions with new random
values.  I was pleasantly surprised by how fast this goes!  It's hard to
conceive of an algorithm that could special-case for this effectively.
Plus it's exactly what happens if a burst of gamma rays corrupts your
sorted database on disk <wink>.

 i    2**i  *sort  ...  %sort
15   32768   0.18  ...   0.03
16   65536   0.24  ...   0.04
17  131072   0.53  ...   0.08
18  262144   1.17  ...   0.16
19  524288   2.56  ...   0.35
20 1048576   5.54  ...   0.77
2002-08-02 05:46:09 +00:00
Tim Peters 7ea39b135a New test "+sort", tacking 10 random floats on to the end of a sorted
array.  Our samplesort special-cases the snot out of this, running about
12x faster than *sort.  The experimental mergesort runs it about 8x
faster than *sort without special-casing, but should really do better
than that (when merging runs of different lengths, right now it only
does something clever about finding where the second run begins in
the first and where the first run ends in the second, and that's more
of a temp-memory optimization).
2002-07-21 17:37:03 +00:00
Tim Peters 0a30e648e0 Added new test "3sort". This is sorted data but with 3 random exchanges.
It's a little better than average for our sort.
2002-07-20 04:21:51 +00:00
Tim Peters 8b6ec79b74 Gave this a facelift: "/" vs "//", whrandom vs random, etc. Boosted
the default range to end at 2**20 (machines are much faster now).
Fixed what was quite a arguably a bug, explaining an old mystery:  the
"!sort" case here contructs what *was* a quadratic-time disaster for
the old quicksort implementation.  But under the current samplesort, it
always ran much faster than *sort (the random case).  This never made
sense.  Turns out it was because !sort was sorting an integer array,
while all the other cases sort floats; and comparing ints goes much
quicker than comparing floats in Python.  After changing !sort to chew
on floats instead, it's now slower than the random sort case, which
makes more sense (but is just a few percent slower; samplesort is
massively less sensitive to "bad patterns" than quicksort).
2002-07-18 15:53:32 +00:00
Andrew M. Kuchling a9745611de Use random instead of whrandom 2002-04-10 14:54:39 +00:00
Eric S. Raymond fc170b1fd5 String method conversion. 2001-02-09 11:51:27 +00:00
Guido van Rossum 16653cb273 Add Tim's worst case scenario.
Revert to using whrandom so it will work with older versions of Python.
1998-05-26 15:05:12 +00:00
Guido van Rossum b26a1b4e2b Use random instead of whrandom. 1998-05-20 17:05:52 +00:00
Guido van Rossum b298a300dd Reduce memory requirements. 1998-05-12 13:21:31 +00:00
Guido van Rossum 03e35c548f Add a few doc strings. 1998-05-10 18:27:29 +00:00
Guido van Rossum ea176b663e benchmark for list.sort() 1998-05-10 18:20:05 +00:00