summaryrefslogtreecommitdiff
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Fix for SF bug 571885Jeremy Hylton2002-06-201-2/+2
| | | | | When resizing a tuple, zero out the memory starting at the end of the old tuple not at the beginning of the old tuple.
* SF 569257 -- Name mangle double underscored variable names in __slots__.Raymond Hettinger2002-06-201-1/+21
|
* Fix the bug described inMichael W. Hudson2002-06-191-5/+9
| | | | | | | | | 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.
* Patch from SF bug 570483 (Tim Northover).Guido van Rossum2002-06-181-0/+5
| | | | | | In a fresh interpreter, type.mro(tuple) would segfault, because PyType_Ready() isn't called for tuple yet. To fix, call PyType_Ready(type) if type->tp_dict is NULL.
* About the new but unreferenced new_class, Guido sez:Michael W. Hudson2002-06-181-15/+0
| | | | | | | > Looks like an experiment by Oren Tirosh that didn't get nuked. I > think you can safely lose it. It's gone.
* SF patch 568629 by Oren Tirosh: types made callable.Guido van Rossum2002-06-145-9/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These built-in functions are replaced by their (now callable) type: slice() buffer() and these types can also be called (but have no built-in named function named after them) classobj (type name used to be "class") code function instance instancemethod (type name used to be "instance method") The module "new" has been replaced with a small backward compatibility placeholder in Python. A large portion of the patch simply removes the new module from various platform-specific build recipes. The following binary Mac project files still have references to it: Mac/Build/PythonCore.mcp Mac/Build/PythonStandSmall.mcp Mac/Build/PythonStandalone.mcp [I've tweaked the code layout and the doc strings here and there, and added a comment to types.py about StringTypes vs. basestring. --Guido]
* Inexplicably, recurse_down_subclasses() was comparing the objectGuido van Rossum2002-06-141-1/+2
| | | | | | gotten from a weak reference to NULL instead of to None. This caused the following assert() to fail (but only in 2.2 in the debug build -- I have to find a better test case). Will backport.
* Missed one use of new PyDoc_STRVAR macroNeal Norwitz2002-06-141-2/+2
|
* SF bug # 493951 string.{starts,ends}with vs slicesNeal Norwitz2002-06-141-45/+36
| | | | Handle negative indices similar to slices.
* SF # 533070 Silence AIX C Compiler WarningsNeal Norwitz2002-06-131-1/+1
| | | | Warning caused by using &func. & is not necessary.
* Major cleanup operation: whenever there's a call that looks for anGuido van Rossum2002-06-131-10/+59
| | | | | | | | | | | | | optional attribute, only clear the exception when the internal getattr operation raised AttributeError. Many places in this file already had that policy; but just as many didn't, and there didn't seem to be any rhyme or reason to it. Be consistently cautious. Question: should I backport this? On the one hand it's a bugfix. On the other hand it's a change in behavior. Certain forms of buggy or just weird code would work in the past but raise an exception under the new rules; e.g. if you define a __getattr__ method that raises a non-AttributeError exception.
* Fix for SF bug 532646. This is a little simpler than what NealGuido van Rossum2002-06-131-1/+17
| | | | | suggested there, based upon a better analysis (__getattr__ is a red herring). Will backport to 2.2.
* SF # 561244 Micro optimizationsNeal Norwitz2002-06-131-5/+3
| | | | Cleanup code a bit and return as early as possible.
* Fix typo in exception messageNeal Norwitz2002-06-131-1/+1
|
View Lorry Controller Status