summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* Tim found that once test_longexp has run, test_sort takes very muchGuido van Rossum2002-08-011-5/+3
| | | | | | | | | | | | longer to run than normal. A profiler run showed that this was due to PyFrame_New() taking up an unreasonable amount of time. A little thinking showed that this was due to the while loop clearing the space available for the stack. The solution is to only clear the local variables (and cells and free variables), not the space available for the stack, since anything beyond the stack top is considered to be garbage anyway. Also, use memset() instead of a while loop counting backwards. This should be a time savings for normal code too! (By a probably unmeasurable amount. :-)
* SF patch 588728 (Nathan Srebro).Guido van Rossum2002-08-011-0/+18
| | | | | | | | The __delete__ method wrapper for descriptors was not supported (I added a test, too.) 2.2 bugfix candidate.
* Replaced samplesort with a stable, adaptive mergesort.Tim Peters2002-08-011-406/+772
|
* Checking in the doc file for "timsort". There's way too much here toTim Peters2002-08-011-0/+618
| | | | | stuff into code comments, and lots of it is going to be useful again (but hard to predict exactly which parts of it ...).
* SF patch #587889, fix memory leak of tp_docNeal Norwitz2002-07-301-0/+1
|
* Fix forMichael W. Hudson2002-07-291-3/+8
| | | | | | [ 587875 ] crash on deleting extended slice The array code got simpler, always a good thing!
* Excise DL_IMPORT/EXPORT from object.h, and related files. This patchMark Hammond2002-07-291-2/+2
| | | | | also adds 'extern' to PyAPI_DATA rather than at each declaration, as discussed with Tim and Guido.
* Fix the problem of not raising a TypeError exception when doing:Neal Norwitz2002-07-281-8/+8
| | | | | | | | '%g' % '1' '%d' % '1' Add a test for these conditions Fix the test so that if not exception is raise, this is a failure
* Patch #574867: Correct list.extend docstring.Martin v. Löwis2002-07-281-1/+1
|
* SF patch #577031, remove PyArg_Parse() since it's deprecatedNeal Norwitz2002-07-281-2/+8
|
* Patch #554716: Use __va_copy where available.Martin v. Löwis2002-07-282-0/+8
|
* tighten up the unicode object's docstring a tadSkip Montanaro2002-07-261-2/+2
|
* Don't be so hasty. If PyInt_AsLong() raises an error, don't set ValueError.Jeremy Hylton2002-07-251-0/+2
|
* Complain if __len__() returns < 0, just like classic classes.Jeremy Hylton2002-07-251-0/+5
| | | | | | Fixes SF bug #575773. Bug fix candidate.
* Silly typo. Not sure how that got in.Michael W. Hudson2002-07-191-1/+1
|
* A few days ago, Guido said (in the thread "[Python-Dev] PythonMichael W. Hudson2002-07-191-1/+34
| | | | | | | | version of PySlice_GetIndicesEx"): > OK. Michael, if you want to check in indices(), go ahead. Then I did what was needed, but didn't check it in. Here it is.
* More sort cleanup: Moved the special cases from samplesortslice intoTim Peters2002-07-191-65/+73
| | | | | | | | | | | 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.
* binarysort() cleanup: Documented the key invariants, explained why theyTim Peters2002-07-191-2/+13
| | | | imply this is a stable sort, and added some asserts.
* listreverse(): Don't call the new reverse_slice unless the listTim Peters2002-07-191-1/+2
| | | | has something in it (else ob_item may be a NULL pointer).
* Cleanup yielding a small speed boost: before rich comparisons wereTim Peters2002-07-191-50/+32
| | | | | | | | | | | | | | | | | | 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.
* Trimmed trailing whitespace.Tim Peters2002-07-191-22/+22
|
* Cleanup: Define one internal utility for reversing a list slice, andTim Peters2002-07-191-28/+20
| | | | use that everywhere.
* Remove extraneous semicolon.Jeremy Hylton2002-07-181-1/+1
| | | | (Silences compiler warning for Compaq C++ 6.5 on Tru64.)
* staticforward bites the dust.Jeremy Hylton2002-07-1711-22/+23
| | | | | | | | | | | | | | | 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.
* Remove the next() method -- one is supplied automatically byGuido van Rossum2002-07-161-16/+11
| | | | | | | | PyType_Ready() because the tp_iternext slot is set (fortunately, because using the tp_iternext implementation for the the next() implementation is buggy). Also changed the allocation order in enum_next() so that the underlying iterator is only moved ahead when we have successfully allocated the result tuple and index.
* Remove the next() method -- one is supplied automatically byGuido van Rossum2002-07-161-10/+1
| | | | | | PyType_Ready() because the tp_iternext slot is set. Also removed the redundant (and expensive!) call to raise StopIteration from rangeiter_next().
* Make StopIteration a sink state. This is done by clearing out theGuido van Rossum2002-07-161-28/+11
| | | | | | | | | | di_dict field when the end of the list is reached. Also make the error ("dictionary changed size during iteration") a sticky state. 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).
* Make StopIteration a sink state. This is done by clearing out theGuido van Rossum2002-07-161-62/+47
| | | | | | | | | | object references (it_seq for seqiterobject, it_callable and it_sentinel for calliterobject) when the end of the list is reached. Also remove the next() methods -- 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).
* Whitespace normalization.Guido van Rossum2002-07-161-66/+66
|
* Make StopIteration a sink state. This is done by clearing out theGuido van Rossum2002-07-161-11/+10
| | | | | | | | | 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).
* The object returned by tp_new() may not have a tp_init.Jeremy Hylton2002-07-161-1/+2
| | | | | | If the object is an ExtensionClass, for example, the slot is not even defined. So we must check that the type has the slot (implied by HAVE_CLASS) before calling tp_init().
* Make list_iter() really static.Guido van Rossum2002-07-161-1/+1
|
* valid_identifier(): use an unsigned char* so that isalpha() will doGuido van Rossum2002-07-161-2/+2
| | | | the right thing even if char is unsigned.
* docompare(): Another reasonable optimization from Jonathan Hogg for theTim Peters2002-07-151-1/+1
| | | | | | 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).
* WINDOWS_LEAN_AND_MEAN: There is no such symbol, although a very fewTim Peters2002-07-141-1/+1
| | | | | | | MSDN sample programs use it, apparently in error. The correct name is WIN32_LEAN_AND_MEAN. After switching to the correct name, in two cases more was needed because the code actually relied on things that disappear when WIN32_LEAN_AND_MEAN is defined.
* Undef MIN and MAX before defining them, to avoid warnings on certainGuido van Rossum2002-07-131-0/+2
| | | | platforms.
* Don't declare a function with staticforward.Jeremy Hylton2002-07-131-2/+2
| | | | | Just declare it static so that lame (BAD_STATIC_FORWARD) compilers don't see a mismatch between the prototype and the function.
* docompare(): Use PyTuple_New instead of Py_BuildValue to build compare'sTim Peters2002-07-111-2/+7
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Extend function() to support an optional closure argument.Jeremy Hylton2002-07-111-12/+65
| | | | Also, simplify some ref counting for other optional arguments.
* object.h special-build macro minefield: renamed all the new lexicalTim Peters2002-07-115-97/+72
| | | | | | | | | | | | | | | | | | | | | | | | | helper macros to something saner, and used them appropriately in other files too, to reduce #ifdef blocks. classobject.c, instance_dealloc(): One of my worst Python Memories is trying to fix this routine a few years ago when COUNT_ALLOCS was defined but Py_TRACE_REFS wasn't. The special-build code here is way too complicated. Now it's much simpler. Difference: in a Py_TRACE_REFS build, the instance is no longer in the doubly-linked list of live objects while its __del__ method is executing, and that may be visible via sys.getobjects() called from a __del__ method. Tough -- the object is presumed dead while its __del__ is executing anyway, and not calling _Py_NewReference() at the start allows enormous code simplification. typeobject.c, call_finalizer(): The special-build instance_dealloc() pain apparently spread to here too via cut-'n-paste, and this is much simpler now too. In addition, I didn't understand why this routine was calling _PyObject_GC_TRACK() after a resurrection, since there's no plausible way _PyObject_GC_UNTRACK() could have been called on the object by this point. I suspect it was left over from pasting the instance_delloc() code. Instead asserted that the object is still tracked. Caution: I suspect we don't have a test that actually exercises the subtype_dealloc() __del__-resurrected-me code.
* Documented PYMALLOC_DEBUG. This completes primary coverage of all theTim Peters2002-07-101-1/+1
| | | | | "special builds" I ever use. If you use others, document them here, or don't be surprised if I rip out the code for them <0.5 wink>.
* The Py_REF_DEBUG/COUNT_ALLOCS/Py_TRACE_REFS macro minefield: addedTim Peters2002-07-091-0/+15
| | | | | | | | | | | | | | | | | | | | | more trivial lexical helper macros so that uses of these guys expand to nothing at all when they're not enabled. This should help sub- standard compilers that can't do a good job of optimizing away the previous "(void)0" expressions. Py_DECREF: There's only one definition of this now. Yay! That was that last one in the family defined multiple times in an #ifdef maze. Py_FatalError(): Changed the char* signature to const char*. _Py_NegativeRefcount(): New helper function for the Py_REF_DEBUG expansion of Py_DECREF. Calling an external function cuts down on the volume of generated code. The previous inline expansion of abort() didn't work as intended on Windows (the program often kept going, and the error msg scrolled off the screen unseen). _Py_NegativeRefcount calls Py_FatalError instead, which captures our best knowledge of how to abort effectively across platforms.
* SF bug 578752: COUNT_ALLOCS vs heap typesTim Peters2002-07-081-0/+9
| | | | | | | Repair segfaults and infinite loops in COUNT_ALLOCS builds in the presence of new-style (heap-allocated) classes/types. Bugfix candidate. I'll backport this to 2.2. It's irrelevant in 2.1.
* Rearranged and added comments to object.h, to clarify many thingsTim Peters2002-07-071-6/+2
| | | | | | | | | | | that have taken me "too long" to reverse-engineer over the years. Vastly reduced the nesting level and redundancy of #ifdef-ery. Took a light stab at repairing comments that are no longer true. sys_gettotalrefcount(): Changed to enable under Py_REF_DEBUG. It was enabled under Py_TRACE_REFS, which was much heavier than necessary. sys.gettotalrefcount() is now available in a Py_REF_DEBUG-only build.
* Removed 3 unlikely #includes that were only needed for the non-gc flavorTim Peters2002-07-071-5/+0
| | | | of the trashcan code.
* Trashcan cleanup: Now that cyclic gc is always there, the trashcanTim Peters2002-07-071-50/+40
| | | | | | | | | | | | | | | | | | | mechanism is no longer evil: it no longer plays dangerous games with the type pointer or refcounts, and objects in extension modules can play along too without needing to edit the core first. Rewrote all the comments to explain this, and (I hope) give clear guidance to extension authors who do want to play along. Documented all the functions. Added more asserts (it may no longer be evil, but it's still dangerous <0.9 wink>). Rearranged the generated code to make it clearer, and to tolerate either the presence or absence of a semicolon after the macros. Rewrote _PyTrash_destroy_chain() to call tp_dealloc directly; it was doing a Py_DECREF again, and that has all sorts of obscure distorting effects in non-release builds (Py_DECREF was already called on the object!). Removed Christian's little "embedded change log" comments -- that's what checkin messages are for, and since it was impossible to correlate the comments with the code that changed, I found them merely distracting.
* Removed WITH_CYCLE_GC #ifdef-ery. Holes:Tim Peters2002-07-072-46/+0
| | | | | | + I'm not sure what to do about configure.in. Left it alone. + Ditto pyexpat.c. Fred or Martin will know what to do.
* Patch #569753: Remove support for WIN16.Martin v. Löwis2002-06-302-6/+6
| | | | Rename all occurrences of MS_WIN32 to MS_WINDOWS.
* Fix SF bug 546434 -- buffer slice type inconsistent.Raymond Hettinger2002-06-251-13/+0
|
* Fix SF bug 572567: Memory leak in object comparison.Raymond Hettinger2002-06-241-0/+1
|
generated by cgit v0.12 at 2025-01-15 21:44:43 (GMT)