Commit Graph

229 Commits

Author SHA1 Message Date
Raymond Hettinger 7832cd6141 Apply tuple/list pre-sizing optimization to a broader class of objects.
Formerly, length data fetched from sequence objects.
Now, any object that reports its length can benefit from pre-sizing.

On one sample timing, it gave a threefold speedup for list(s) where s
was a set object.
2004-01-04 06:08:16 +00:00
Andrew MacIntyre f1ca7f561c complete backout of listobject.c v2.171 2003-12-28 07:43:56 +00:00
Jeremy Hylton 30973414c5 Revert previous two checkins to repair test failure.
The special-case code that was removed could return a value indicating
success but leave an exception set.  test_fileinput failed in a debug
build as a result.
2003-12-26 19:05:04 +00:00
Andrew MacIntyre 694e3a4a9d use the correct macro to access list size 2003-12-26 00:09:04 +00:00
Andrew MacIntyre d57caed52c Performance of list([]) in 2.3 came up in a thread on comp.lang.python,
which can be reviewed via
http://coding.derkeiler.com/Archive/Python/comp.lang.python/2003-12/1011.html

Duncan Booth investigated, and discovered that an "optimisation" was
in fact a pessimisation for small numbers of elements in a source list,
compared to not having the optimisation, although with large numbers
of elements in the source list the optimisation was quite beneficial.

He posted his change to comp.lang.python (but not to SF).

Further research has confirmed his assessment that the optimisation only
becomes a net win when the source list has more than 100 elements.

I also found that the optimisation could apply to tuples as well,
but the gains only arrive with source tuples larger than about 320
elements and are nowhere near as significant as the gains with lists,
(~95% gain @ 10000 elements for lists, ~20% gain @ 10000 elements for
tuples) so I haven't proceeded with this.

The code as it was applied the optimisation to list subclasses as
well, and this also appears to be a net loss for all reasonable sized
sources (~80-100% for up to 100 elements, ~20% for more than 500
elements; I tested up to 10000 elements).

Duncan also suggested special casing empty lists, which I've extended
to all empty sequences.

On the basis that list_fill() is only ever called with a list for the
result argument, testing for the source being the destination has
now happens before testing source types.
2003-12-25 13:28:48 +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
Raymond Hettinger 8f5cdaa784 * Added a new method flag, METH_COEXIST.
* Used the flag to optimize set.__contains__(), dict.__contains__(),
  dict.__getitem__(), and list.__getitem__().
2003-12-13 11:26:12 +00:00
Hye-Shik Chang 19cb193244 Fix memory error treatment correctly. Going to dsu_fail causes
deallocating garbage pointers; saved_ob_item and empty_ob_item.
(Reviewed by Raymond Hettinger)
2003-12-10 07:31:08 +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 001f228f36 Improve the reverse list iterator to free memory as soon as the iterator
is exhausted.
2003-11-08 11:58:44 +00:00
Raymond Hettinger c24c9106e8 Minor code fixup. Make sure that len reflects the current list size. 2003-11-08 11:35:22 +00:00
Raymond Hettinger 1021c44b41 Optimize reversed(list) using a custom iterator. 2003-11-07 15:38:09 +00:00
Jeremy Hylton ceac90aecb Fix compiler warning about possible use of n without assignment.
Also fix use of n for two different variables in two different blocks.
2003-11-03 20:58:28 +00:00
Raymond Hettinger 0a9b9da0c3 Add list.sorted() classmethod. 2003-10-29 06:54:43 +00:00
Raymond Hettinger ae4a299a0d Fix typo found by Neal Norwitz. 2003-10-16 17:16:30 +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
Michael W. Hudson da0a0673b1 My last fix left n used unitialized in tha a==b case.
Fix, by not using n at all in that case.

Needs to be applied to release23-maint, too.
2003-08-15 12:06:41 +00:00
Michael W. Hudson b4f49385a3 Fix reference leak noted in test_types:
Check for a[:] = a _before_ calling PySequence_Fast on a.
release23-maint candidate
Reference leak doesn't happen with head of release22-maint.
2003-08-14 17:04:28 +00:00
Walter Dörwald e8049befdf Use _PyEval_SliceIndex to handle list.index() calls with
huge start and stop arguments. Add tests.
2003-06-17 19:27:39 +00:00
Guido van Rossum 2743d87d79 Fix sloppy index() implementation:
- don't use min() and max()
- interpret negative start/stop argument like negative slice indices
2003-06-17 14:25:14 +00:00
Raymond Hettinger d05abdec7b SF #754014: list.index() should accept optional start, end arguments
Also, modified UserList.index() to match and expanded the related tests.
2003-06-17 05:05:49 +00:00
Raymond Hettinger 6624e68546 SF bug #604716: faster [None]*n or []*n
Fulfilled request to special case repetitions of lists of length 0 or 1.
2003-05-21 05:58:46 +00:00
Raymond Hettinger 686b14d7ad SF bug #730296: Unexpected Changes in list Iterator
Reverted a Py2.3b1 change to iterator in subclasses of list and tuple.
They had been changed to use __getitem__ whenever it had been overriden
in the subclass.

This caused some usabilty and performance problems.  Also, it was
inconsistent with the rest of python where many container methods
access the underlying object directly without first checking for
an overridden getter.  Users needing a change in iterator behavior
should override it directly.
2003-05-07 01:28:47 +00:00
Martin v. Löwis cd12bfc142 Patch #708604: Check more function results. Will backport to 2.2. 2003-05-03 10:53:08 +00:00
Tim Peters 2af713c2f7 Squashed new compiler wngs about trying to compare pointers to
functions with different signatures.
2003-04-24 20:59:52 +00:00
Raymond Hettinger 9928571f3f SF bug 665835: filter() treatment of str and tuple inconsistent
As a side issue on this bug, it was noted that list and tuple iterators
used macros to directly access containers and would not recognize
__getitem__ overrides.  If the method is overridden, the patch returns
a generic sequence iterator which calls the __getitem__ method; otherwise,
it returns a high custom iterator with direct access to container elements.
2003-04-24 16:52:47 +00:00
Guido van Rossum 3a3cca5b82 - list.insert(i, x) now interprets negative i as it would be
interpreted by slicing, so negative values count from the end of the
  list.  This was the only place where such an interpretation was not
  placed on a list index.
2003-04-14 20:58:14 +00:00
Raymond Hettinger 1da1dbf458 Renamed PyObject_GenericGetIter to PyObject_SelfIter
to more accurately describe what the function does.

Suggested by Thomas Wouters.
2003-03-17 19:46:11 +00:00
Raymond Hettinger 0153826964 Created PyObject_GenericGetIter().
Factors out the common case of returning self.
2003-03-17 08:24:35 +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
Raymond Hettinger ea3fdf44a2 SF patch #659536: Use PyArg_UnpackTuple where possible.
Obtain cleaner coding and a system wide
performance boost by using the fast, pre-parsed
PyArg_Unpack function instead of PyArg_ParseTuple
function which is driven by a format string.
2002-12-29 16:33:45 +00:00
Raymond Hettinger f8bcfb13f1 SF Bug 645777: list.extend() works with any iterable and is no longer
experimental.
2002-12-29 05:49:09 +00:00
Michael W. Hudson a69c030c15 The final tweaks before closing
[ 633152 ] list slice ass ignores subtypes of list

Allow arbitrary sequences on the RHS of extended slices.
2002-12-05 21:32:32 +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
Neal Norwitz 03b109afc0 Use PyOS_snprintf() instead of sprintf and wrap the long line 2002-11-05 22:41:37 +00:00
Michael W. Hudson 5da854fe51 This is Alex Martelli's patch
[ 633870 ] allow any seq assignment to a list slice

plus a very silly little test case of my own.
2002-11-05 17:38:05 +00:00
Guido van Rossum bfa5a14adb Darn! Don't divide by zero. Bad fix. :-) 2002-10-11 23:39:35 +00:00
Guido van Rossum a5c0e6d6c8 Add checks for size overflow on list*n, list+list, tuple+tuple.
Will backport.
2002-10-11 21:05:56 +00:00
Neal Norwitz bb9c5f5032 PyObject_RichCompareBool() already returns -1, 0, or 1, so return its value 2002-09-05 21:32:55 +00:00
Raymond Hettinger aae5999b44 Micro-optimization for list_contains. Factored double if test
out of the loop.
2002-09-05 14:23:49 +00:00
Tim Peters e05f65a0c6 1. Combined the base and length arrays into a single array of structs.
This is friendlier for caches.

2. Cut MIN_GALLOP to 7, but added a per-sort min_gallop vrbl that adapts
   the "get into galloping mode" threshold higher when galloping isn't
   paying, and lower when it is.  There's no known case where this hurts.
   It's (of course) neutral for /sort, \sort and =sort.  It also happens
   to be neutral for !sort.  It cuts a tiny # of compares in 3sort and +sort.
   For *sort, it reduces the # of compares to better than what this used to
   do when MIN_GALLOP was hardcoded to 10 (it did about 0.1% more *sort
   compares before, but given how close we are to the limit, this is "a
   lot"!).  %sort used to do about 1.5% more compares, and ~sort about
   3.6% more.  Here are exact counts:

 i    *sort    3sort    +sort    %sort    ~sort    !sort
15   449235    33019    33016    51328   188720    65534  before
     448885    33016    33007    50426   182083    65534  after
      0.08%    0.01%    0.03%    1.79%    3.65%    0.00%  %ch from after

16   963714    65824    65809   103409   377634   131070
     962991    65821    65808   101667   364341   131070
      0.08%    0.00%    0.00%    1.71%    3.65%    0.00%

17  2059092   131413   131362   209130   755476   262142
    2057533   131410   131361   206193   728871   262142
      0.08%    0.00%    0.00%    1.42%    3.65%    0.00%

18  4380687   262440   262460   421998  1511174   524286
    4377402   262437   262459   416347  1457945   524286
      0.08%    0.00%    0.00%    1.36%    3.65%    0.00%

19  9285709   524581   524634   848590  3022584  1048574
    9278734   524580   524633   837947  2916107  1048574
      0.08%    0.00%    0.00%    1.27%    3.65%    0.00%

20 19621118  1048960  1048942  1715806  6045418  2097150
   19606028  1048958  1048941  1694896  5832445  2097150
      0.08%    0.00%    0.00%    1.23%    3.65%    0.00%

3. Added some key asserts I overlooked before.

4. Updated the doc file.
2002-08-10 05:21:15 +00:00
Tim Peters 6063e2615f PyList_Reverse(): This was leaking a reference to Py_None on every call.
I believe I introduced this bug when I refactored the reversal code so
that the mergesort could use it too.  It's not a problem on the 2.2 branch.
2002-08-08 01:06:39 +00:00
Tim Peters 66860f6da4 Sped the usual case for sorting by calling PyObject_RichCompareBool
directly when no comparison function is specified.  This saves a layer
of function call on every compare then.  Measured speedups:

 i    2**i  *sort  \sort  /sort  3sort  +sort  %sort  ~sort  =sort  !sort
15   32768  12.5%   0.0%   0.0% 100.0%   0.0%  50.0% 100.0% 100.0% -50.0%
16   65536   8.7%   0.0%   0.0%   0.0%   0.0%   0.0%  12.5%   0.0%   0.0%
17  131072   8.0%  25.0%   0.0%  25.0%   0.0%  14.3%   5.9%   0.0%   0.0%
18  262144   6.3% -10.0%  12.5%  11.1%   0.0%   6.3%   5.6%  12.5%   0.0%
19  524288   5.3%   5.9%   0.0%   5.6%   0.0%   5.9%   5.4%   0.0%   2.9%
20 1048576   5.3%   2.9%   2.9%   5.1%   2.8%   1.3%   5.9%   2.9%   4.2%

The best indicators are those that take significant time (larger i), and
where sort doesn't do very few compares (so *sort and ~sort benefit most
reliably).  The large numbers are due to roundoff noise combined with
platform variability; e.g., the 14.3% speedup for %sort at i=17 reflects
a printed elapsed time of 0.18 seconds falling to 0.17, but a change in
the last digit isn't really meaningful (indeed, if it really took 0.175
seconds, one electron having a lazy nanosecond could shift it to either
value <wink>).  Similarly the 25% at 3sort i=17 was a meaningless change
from 0.05 to 0.04.  However, almost all the "meaningless changes" were
in the same direction, which is good.  The before-and-after times for
*sort are clearest:

before after
  0.18  0.16
  0.25  0.23
  0.54  0.50
  1.18  1.11
  2.57  2.44
  5.58  5.30
2002-08-04 17:47:26 +00:00
Tim Peters 6bdbc9e0b1 SF bug 590366: Small typo in listsort:ParseTuple
The PyArg_ParseTuple() error string still said "msort".  Changed to "sort".
2002-08-03 02:28:24 +00:00
Tim Peters a64dc245ac Replaced samplesort with a stable, adaptive mergesort. 2002-08-01 02:13:36 +00:00
Michael W. Hudson 56796f672f Fix for
[ 587875 ] crash on deleting extended slice

The array code got simpler, always a good thing!
2002-07-29 14:35:04 +00:00
Martin v. Löwis 673c0a2247 Patch #574867: Correct list.extend docstring. 2002-07-28 16:35:57 +00:00
Tim Peters 330f9e9581 More sort cleanup: Moved the special cases from samplesortslice into
listsort.  If the former calls itself recursively, they're a waste of
time, since it's called on a random permutation of a random subset of
elements.  OTOH, for exactly the same reason, they're an immeasurably
small waste of time (the odds of finding exploitable order in a random
permutation are ~= 0, so the special-case loops looking for order give
up quickly).  The point is more for conceptual clarity.
Also changed some "assert comments" into real asserts; when this code
was first written, Python.h didn't supply assert.h.
2002-07-19 07:05:44 +00:00
Tim Peters 0fe977c4a9 binarysort() cleanup: Documented the key invariants, explained why they
imply this is a stable sort, and added some asserts.
2002-07-19 06:12:32 +00:00
Tim Peters 326b44871e listreverse(): Don't call the new reverse_slice unless the list
has something in it (else ob_item may be a NULL pointer).
2002-07-19 04:04:16 +00:00
Tim Peters a8c974c157 Cleanup yielding a small speed boost: before rich comparisons were
introduced, list.sort() was rewritten to use only the "< or not <?"
distinction.  After rich comparisons were introduced, docompare() was
fiddled to translate a Py_LT Boolean result into the old "-1 for <,
0 for ==, 1 for >" flavor of outcome, and the sorting code was left
alone.  This left things more obscure than they should be, and turns
out it also cost measurable cycles.

So:  The old CMPERROR novelty is gone.  docompare() is renamed to islt(),
and now has the same return conditinos as PyObject_RichCompareBool.  The
SETK macro is renamed to ISLT, and is even weirder than before (don't
complain unless you want to maintain the sort code <wink>).

Overall, this yields a 1-2% speedup in the usual (no explicit function
passed to list.sort()) case when sorting arrays of floats (as sortperf.py
does).  The boost is higher for arrays of ints.
2002-07-19 03:30:57 +00:00
Tim Peters 3b01a1217f Trimmed trailing whitespace. 2002-07-19 02:35:45 +00:00
Tim Peters 8e2e7ca330 Cleanup: Define one internal utility for reversing a list slice, and
use that everywhere.
2002-07-19 02:33:08 +00:00
Jeremy Hylton 938ace69a0 staticforward bites the dust.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure.  Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers.  (In
fact, we expect that the compilers are all fixed eight years later.)

I'm leaving staticforward and statichere defined in object.h as
static.  This is only for backwards compatibility with C extensions
that might still use it.

XXX I haven't updated the documentation.
2002-07-17 16:30:39 +00:00
Guido van Rossum 6b6272c857 Whitespace normalization. 2002-07-16 20:10:23 +00:00
Guido van Rossum 86103ae531 Make StopIteration a sink state. This is done by clearing out the
it_seq field when the end of the list is reached.

Also remove the next() method -- one is supplied automatically by
PyType_Ready() because the tp_iternext slot is set.  That's a good
thing, because the implementation given here was buggy (it never
raised StopIteration).
2002-07-16 20:07:32 +00:00
Guido van Rossum 5086e49a6e Make list_iter() really static. 2002-07-16 15:56:52 +00:00
Tim Peters 58cf361e35 docompare(): Another reasonable optimization from Jonathan Hogg for the
explicit comparison function case:  use PyObject_Call instead of
PyEval_CallObject.  Same thing in context, but gives a 2.4% overall
speedup when sorting a list of ints via list.sort(__builtin__.cmp).
2002-07-15 05:16:13 +00:00
Jeremy Hylton a4b4c3bf05 Don't declare a function with staticforward.
Just declare it static so that lame (BAD_STATIC_FORWARD) compilers
don't see a mismatch between the prototype and the function.
2002-07-13 03:51:17 +00:00
Tim Peters f2a0473350 docompare(): Use PyTuple_New instead of Py_BuildValue to build compare's
arg tuple.  This was suggested on c.l.py but afraid I can't find the msg
again for proper attribution.  For

    list.sort(cmp)

where list is a list of random ints, and cmp is __builtin__.cmp, this
yields an overall 50-60% speedup on my Win2K box.  Of course this is a
best case, because the overhead of calling cmp relative to the cost of
actually comparing two ints is at an extreme.  Nevertheless it's huge
bang for the buck.  An additionak 20-30% can be bought by making the arg
tuple an immortal static (avoiding all but "the first" PyTuple_New), but
that's tricky to make correct since docompare needs to be reentrant.  So
this picks the cherry and leaves the pits for Fred <wink>.

Note that this makes no difference to the

    list.sort()

case; an arg tuple gets built only if the user specifies an explicit
sort function.
2002-07-11 21:46:16 +00:00
Michael W. Hudson 9c14badc5f Fix the bug described in
http://mail.python.org/pipermail/python-dev/2002-June/025461.html

with test cases.

Also includes extended slice support for arrays, which I thought I'd
already checked in but obviously not.
2002-06-19 15:44:15 +00:00
Neal Norwitz 2c2e827029 Missed one use of new PyDoc_STRVAR macro 2002-06-14 02:04:18 +00:00
Neal Norwitz 35fc7606f0 SF #561244 Micro optimizations
Convert loops to memset()s.
2002-06-13 21:11:11 +00:00
Martin v. Löwis 14f8b4cfcb Patch #568124: Add doc string macros. 2002-06-13 20:33:02 +00:00
Guido van Rossum 75a20b19ef Fold remaining long lines. 2002-06-11 12:22:28 +00:00
Michael W. Hudson 5efaf7eac8 This is my nearly two year old patch
[ 400998 ] experimental support for extended slicing on lists

somewhat spruced up and better tested than it was when I wrote it.

Includes docs & tests.  The whatsnew section needs expanding, and arrays
should support extended slices -- later.
2002-06-11 10:55:12 +00:00
Tim Peters 93b2cc4e97 A bogus assert in the new listiter code prevented starting Python in a
debug build.  Repaired that, and rewrote other parts to reduce
long-winded casting.
2002-06-01 05:22:55 +00:00
Raymond Hettinger 14bd6de0ec SF 560736. Optimize list iteration by filling the tp_iter slot. 2002-05-31 21:40:38 +00:00
Neal Norwitz d4e5be5340 Closes: #556025 seg fault when doing list(xrange(1e9))
A MemoryError is now raised when the list cannot be created.
There is a test, but as the comment says, it really only
works for 32 bit systems.  I don't know how to improve
the test for other systems (ie, 64 bit or systems
where the data size != addressable size,
e.g. 64 bit data, but 48 bit addressable memory)
2002-05-22 23:19:17 +00:00
Neil Schemenauer 99b5d28467 PyObject_GC_Del can now be used as a function designator. 2002-04-12 02:44:22 +00:00
Guido van Rossum ff413af605 This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction).
The fix makes it possible to call PyObject_GC_UnTrack() more than once
on the same object, and then move the PyObject_GC_UnTrack() call to
*before* the trashcan code is invoked.

BUGFIX CANDIDATE!
2002-03-28 20:34:59 +00:00
Guido van Rossum dbb53d9918 Fix of SF bug #475877 (Mutable subtype instances are hashable).
Rather than tweaking the inheritance of type object slots (which turns
out to be too messy to try), this fix adds a __hash__ to the list and
dict types (the only mutable types I'm aware of) that explicitly
raises an error.  This has the advantage that list.__hash__([]) also
raises an error (previously, this would invoke object.__hash__([]),
returning the argument's address); ditto for dict.__hash__.

The disadvantage for this fix is that 3rd party mutable types aren't
automatically fixed.  This should be added to the rules for creating
subclassable extension types: if you don't want your object to be
hashable, add a tp_hash function that raises an exception.

Also, it's possible that I've forgotten about other mutable types for
which this should be done.
2001-12-03 16:32:18 +00:00
Guido van Rossum 9475a2310d Enable GC for new-style instances. This touches lots of files, since
many types were subclassable but had a xxx_dealloc function that
called PyObject_DEL(self) directly instead of deferring to
self->ob_type->tp_free(self).  It is permissible to set tp_free in the
type object directly to _PyObject_Del, for non-GC types, or to
_PyObject_GC_Del, for GC types.  Still, PyObject_DEL was a tad faster,
so I'm fearing that our pystone rating is going down again.  I'm not
sure if doing something like

void xxx_dealloc(PyObject *self)
{
	if (PyXxxCheckExact(self))
		PyObject_DEL(self);
	else
		self->ob_type->tp_free(self);
}

is any faster than always calling the else branch, so I haven't
attempted that -- however those types whose own dealloc is fancier
(int, float, unicode) do use this pattern.
2001-10-05 20:51:39 +00:00
Tim Peters 52e0717215 Give the internal immutable list type .extend and .pop methods (they
"should have" been added here when they were added to lists).
2001-08-30 06:15:32 +00:00
Neil Schemenauer e83c00efd0 Use new GC API. 2001-08-29 23:54:21 +00:00
Martin v. Löwis e3eb1f2b23 Patch #427190: Implement and use METH_NOARGS and METH_O. 2001-08-16 13:15:00 +00:00
Tim Peters 6d6c1a35e0 Merge of descr-branch back into trunk. 2001-08-02 04:15:00 +00:00
Tim Peters 6ee4234802 SF bug #439104: Tuple richcompares has code-typo.
Symptom:  (1, 2, 3) <= (1, 2) returned 1.
This was already fixed in CVS for tuples, but an isomorphic error was in
the list richcompare code.
2001-07-06 17:45:43 +00:00
Tim Peters a7259597f1 SF bug 433228: repr(list) woes when len(list) big.
Gave Python linear-time repr() implementations for dicts, lists, strings.
This means, e.g., that repr(range(50000)) is no longer 50x slower than
pprint.pprint() in 2.2 <wink>.

I don't consider this a bugfix candidate, as it's a performance boost.

Added _PyString_Join() to the internal string API.  If we want that in the
public API, fine, but then it requires runtime error checks instead of
asserts.
2001-06-16 05:11:17 +00:00
Tim Peters 1af03e98d9 Change list.extend() error msgs and NEWS to reflect that list.extend()
now takes any iterable argument, not only sequences.

NEEDS DOC CHANGES -- but I don't think we settled on a concise way to
say this stuff.
2001-05-26 19:37:54 +00:00
Tim Peters 442914d265 Cruft cleanup: removed the #ifdef'ery in support of compiling to allow
multi-argument list.append(1, 2, 3) (as opposed to .append((1,2,3))).
2001-05-26 05:50:03 +00:00
Tim Peters 65b8b84839 roundupsize() and friends: fiddle over-allocation strategy for list
resizing.

Accurate timings are impossible on my Win98SE box, but this is obviously
faster even on this box for reasonable list.append() cases.  I give
credit for this not to the resizing strategy but to getting rid of integer
multiplication and divsion (in favor of shifting) when computing the
rounded-up size.

For unreasonable list.append() cases, Win98SE now displays linear behavior
for one-at-time appends up to a list with about 35 million elements.  Then
it dies with a MemoryError, due to fatally fragmented *address space*
(there's plenty of VM available, but by this point Win9X has broken user
space into many distinct heaps none of which has enough contiguous space
left to resize the list, and for whatever reason Win9x isn't coalescing
the dead heaps).  Before the patch it got a MemoryError for the same
reason, but once the list reached about 2 million elements.

Haven't yet tried on Win2K but have high hopes extreme list.append()
will be much better behaved now (NT & Win2K didn't fragment address space,
but suffered obvious quadratic-time behavior before as lists got large).

For other systems I'm relying on common sense:  replacing integer * and /
by << and >> can't plausibly hurt, the number of function calls hasn't
changed, and the total operation count for reasonably small lists is about
the same (while the operations are cheaper now).
2001-05-26 05:28:40 +00:00
Guido van Rossum b86c549c7c Fix core dump whenever PyList_Reverse() was called.
This fixes SF bug #132008, reported by Warren J. Hack.

The copyright for this patch (and this patch only) belongs to CNRI, as
part of the (yet to be issued) 1.6.1 release.

This is now checked into the HEAD branch.  Tim will check in a test
case to check for this specific bug, and an assertion in
PyArgs_ParseTuple() to catch similar bugs in the future.
2001-02-12 22:06:02 +00:00
Guido van Rossum 65e1cea6e3 Convert to rich comparisons:
- sort's docompare() calls RichCompare(Py_LT).

- list_contains(), list_index(), listcount(), listremove() call
  RichCompare(Py_EQ).

- Get rid of list_compare(), in favor of new list_richcompare().  The
  latter does some nice shortcuts, like when == or != is requested, it
  first compares the lengths for trivial accept/reject.  Then it goes
  over the items until it finds an index where the items differe; then
  it does more shortcut magic to minimize the number of additional
  comparisons.

- Aligned the comments for large struct initializers.
2001-01-17 22:11:59 +00:00
Jeremy Hylton db60bb5aad fix leak 2001-01-03 22:32:16 +00:00
Tim Peters 0e76ab2ecc Use METH_VARARGS instead of "1" in list method table. 2000-12-13 22:35:46 +00:00
Fred Drake d5fadf75e4 Rationalize use of limits.h, moving the inclusion to Python.h.
Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.

This closes SourceForge patch #101659 and bug #115323.
2000-09-26 05:46:01 +00:00
Guido van Rossum 8586991099 REMOVED all CWI, CNRI and BeOpen copyright markings.
This should match the situation in the 1.6b1 tree.
2000-09-01 23:29:29 +00:00
Thomas Wouters e289e0bd0c Support for the in-place operations introduced by augmented assignment. Only
the list object supports this currently, but other candidates are
gladly accepted (like arraymodule and such.)
2000-08-24 20:08:19 +00:00
Jack Jansen e979160f5e Added include for limits.h 2000-08-22 21:51:22 +00:00
Trent Mick a584664134 Check for overflow in list object insertion and raise OverflowError.
see: http://www.python.org/pipermail/python-dev/2000-August/014971.html
2000-08-13 22:47:45 +00:00
Thomas Wouters 334fb8985b Use 'void' directly instead of the ANY #define, now that all code is ANSI C.
Leave the actual #define in for API compatibility.
2000-07-25 12:56:38 +00:00
Vladimir Marangozov 467a67e74d Fix in PyList_New(). With GC enabled and when out of memory,
free() the GC pointer, not the object pointer.
2000-07-15 03:31:31 +00:00
Jeremy Hylton 03657cfdb0 replace PyXXX_Length calls with PyXXX_Size calls 2000-07-12 13:05:33 +00:00
Fred Drake a2f5511941 ANSI-fication of the sources. 2000-07-09 15:16:51 +00:00
Guido van Rossum 4cc6ac7b87 Neil Schemenauer: small fixes for GC 2000-07-01 01:00:38 +00:00
Guido van Rossum ffcc3813d8 Change copyright notice - 2nd try. 2000-06-30 23:58:06 +00:00
Guido van Rossum fd71b9e9d4 Change copyright notice. 2000-06-30 23:50:40 +00:00
Jeremy Hylton c5007aa5c3 final patches from Neil Schemenauer for garbage collection 2000-06-30 05:02:53 +00:00