summaryrefslogtreecommitdiffstats
path: root/Objects/tupleobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert backwards-incompatible const changes.Martin v. Löwis2006-02-271-1/+1
|
* Use Py_ssize_t for counts and sizes.Martin v. Löwis2006-02-161-3/+4
| | | | Convert Py_ssize_t using PyInt_FromSsize_t
* Merge ssize_t branch.Martin v. Löwis2006-02-151-48/+44
|
* Renamed _length_cue() to __length_hint__(). See:Armin Rigo2006-02-111-2/+2
| | | | http://mail.python.org/pipermail/python-dev/2006-February/060524.html
* Add const to several API functions that take char *.Jeremy Hylton2005-12-101-1/+1
| | | | | | | | | | | | | | | | | | | In C++, it's an error to pass a string literal to a char* function without a const_cast(). Rather than require every C++ extension module to put a cast around string literals, fix the API to state the const-ness. I focused on parts of the API where people usually pass literals: PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type slots, etc. Predictably, there were a large set of functions that needed to be fixed as a result of these changes. The most pervasive change was to make the keyword args list passed to PyArg_ParseTupleAndKewords() to be a const char *kwlist[]. One cast was required as a result of the changes: A type object mallocs the memory for its tp_doc slot and later frees it. PyTypeObject says that tp_doc is const char *; but if the type was created by type_new(), we know it is safe to cast to char *.
* Convert iterator __len__() methods to a private API.Raymond Hettinger2005-09-241-7/+12
|
* Add a final permutation step to the tuple hash function.Raymond Hettinger2004-06-101-0/+1
| | | | | Prevents a collision pattern that occurs with nested tuples. (Yitz Gale provided code that repeatably demonstrated the weakness.)
* Replaced arbitrary addend in tuple_hash with one that is known to generateRaymond Hettinger2004-06-041-1/+9
| | | | many more prime multipliers and that performs well on collision tests.
* SF bug #942952: Weakness in tuple hashRaymond Hettinger2004-06-011-2/+3
| | | | | | | (Basic approach and test concept by Tim Peters.) * Improved the hash to reduce collisions. * Added the torture test to the test suite.
* Restored revision 2.87.Armin Rigo2004-03-211-12/+5
|
* PyTuple_New(): vrbl i no longer referenced, so removed it (which killsTim Peters2004-03-211-1/+1
| | | | off a new compiler wng under MSVC6).
* This is the fastest I could get on Intel GCC. I kept the memset() in to clearArmin Rigo2004-03-211-4/+11
| | | | | | | | the newly created tuples, but tuples added in the freelist are now cleared in tupledealloc already (which is very cheap, because we are already Py_XDECREF'ing all elements anyway). Python should have a standard Py_ZAP macro like ZAP in pystate.c.
* memset() hunt continuing. This is a net win.Armin Rigo2004-03-201-1/+3
|
* Make iterators length transparent where possible.Raymond Hettinger2004-03-181-1/+14
|
* Eliminate an unnecessary test on a common code path.Raymond Hettinger2004-03-151-3/+1
|
* Optimize inner loops for subscript, repeat, and concat.Raymond Hettinger2004-03-091-9/+20
|
* Optimize tuple_slice() and make further improvements to list_slice()Raymond Hettinger2004-03-081-4/+9
| | | | | | and list.extend(). Factoring the inner loops to remove the constant structure references and fixed offsets gives speedups ranging from 20% to 30%.
* Extended tuple's C API to include a new function, PyTuple_Pack() that isRaymond Hettinger2003-10-121-0/+22
| | | | | useful for rapidly building argument tuples without having to invoke the more sophisticated machinery of Py_BuildValue().
* SF bug #730296: Unexpected Changes in list IteratorRaymond Hettinger2003-05-071-2/+0
| | | | | | | | | | | | 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.
* Squashed new compiler wngs about trying to compare pointers toTim Peters2003-04-241-1/+1
| | | | functions with different signatures.
* SF bug 665835: filter() treatment of str and tuple inconsistentRaymond Hettinger2003-04-241-0/+2
| | | | | | | | 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.
* Renamed PyObject_GenericGetIter to PyObject_SelfIterRaymond Hettinger2003-03-171-1/+1
| | | | | | to more accurately describe what the function does. Suggested by Thomas Wouters.
* Created PyObject_GenericGetIter().Raymond Hettinger2003-03-171-9/+1
| | | | Factors out the common case of returning self.
* Implement appropriate __getnewargs__ for all immutable subclassable builtinGuido van Rossum2003-01-291-1/+13
| | | | | | | | types. The special handling for these can now be removed from save_newobj(). Add some testing for this. Also add support for setting the 'fast' flag on the Python Pickler class, which suppresses use of the memo.
* Add checks for size overflow on list*n, list+list, tuple+tuple.Guido van Rossum2002-10-111-0/+2
| | | | Will backport.
* PyObject_RichCompareBool() already returns -1, 0, or 1, so return its valueNeal Norwitz2002-09-051-5/+1
|
* Micro-optimization for list_contains. Factored double if testRaymond Hettinger2002-09-051-7/+6
| | | | out of the loop.
* Call me anal, but there was a particular phrase that was speading toGuido van Rossum2002-08-191-1/+1
| | | | | | | comments everywhere that bugged me: /* Foo is inlined */ instead of /* Inline Foo */. Somehow the "is inlined" phrase always confused me for half a second (thinking, "No it isn't" until I added the missing "here"). The new phrase is hopefully unambiguous.
* Moved special case for tuples from iterobject.c toRaymond Hettinger2002-08-091-1/+112
| | | | | | tupleobject.c. Makes the code in iterobject.c cleaner and speeds-up the general case by not checking for tuples everytime. SF Patch #592065.
* staticforward bites the dust.Jeremy Hylton2002-07-171-1/+1
| | | | | | | | | | | | | | | 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.
* object.h special-build macro minefield: renamed all the new lexicalTim Peters2002-07-111-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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 #561244 Micro optimizationsNeal Norwitz2002-06-131-5/+4
| | | | Convert loops to memset()s.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-2/+2
|
* This is my nearly two year old patchMichael W. Hudson2002-06-111-1/+58
| | | | | | | | | [ 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.
* PyObject_GC_Del can now be used as a function designator.Neil Schemenauer2002-04-121-1/+1
|
* This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction).Guido van Rossum2002-03-281-1/+1
| | | | | | | | 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!
* _PyTuple_Resize(): this dumped core on tuple(globals()) for me. TurnsGuido van Rossum2001-12-071-6/+8
| | | | | | | | | | | out the for loop at the end intended to zero out new items wasn't doing anything, because sv->ob_size was already equal to newsize. The fix slightly refactors the function, introducing a variable oldsize and doing away with sizediff (which was used only once), and using oldsize and newsize consistently. I also added comments explaining what the two for loops do. (Looking at the CVS annotation of this function, it's no miracle a bug crept in -- this has been patched by many different folks! :-)
* Enable GC for new-style instances. This touches lots of files, sinceGuido van Rossum2001-10-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* The endless 460020 bug.Tim Peters2001-09-111-6/+9
| | | | Disable t[:], t*0, t*1 optimizations when t is of a tuple subclass type.
* Rewrite the tuple() docstring to parallel the list() docstring.Tim Peters2001-09-021-4/+4
|
* Repair apparent cut'n'pasteo in tuple() docstring.Tim Peters2001-09-021-1/+1
|
* More stuff discovered while writing the simplest of testcases:Guido van Rossum2001-08-301-2/+5
| | | | | | | tupledealloc(): only feed the free list when the type is really a tuple, not a subtype. Otherwise, use PyObject_GC_Del(). _PyTuple_Resize(): disallow using this for tuple subtypes.
* Make str and tuple types subclassable.Guido van Rossum2001-08-301-2/+30
|
* Use new GC API.Neil Schemenauer2001-08-291-26/+13
|
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-2/+38
|
* SF bug 433228: repr(list) woes when len(list) big.Tim Peters2001-06-161-13/+49
| | | | | | | | | | | | 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.
* _PyTuple_Resize: guard against PyTuple_New() returning NULL, using Tim'sThomas Wouters2001-05-291-1/+1
| | | | suggestion (modulo style).
* Cruft cleanup: Removed the unused last_is_sticky argument from the internalTim Peters2001-05-281-4/+3
| | | | _PyTuple_Resize().
* _PyTuple_Resize: take into account the empty tuple. There can be only one.Thomas Wouters2001-05-281-2/+11
| | | | | | | Instead of raising a SystemError, just create a new tuple of the desired size. This fixes (at least) SF bug #420343.
generated by cgit v0.12 at 2024-11-27 09:31:20 (GMT)