summaryrefslogtreecommitdiffstats
path: root/Objects/tupleobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix error introduced by r58288; if a tuple is length 0 return its repr andBrett Cannon2007-09-301-4/+4
| | | | don't worry about any self-referring tuples.
* tuple.__repr__ did not consider a reference loop as it is not possible fromBrett Cannon2007-09-301-0/+13
| | | | | | | | | | Python code; but it is possible from C. object.__str__ had the issue of not expecting a type to doing something within it's tp_str implementation that could trigger an infinite recursion, but it could in C code.. Both found thanks to BaseException and how it handles its repr. Closes issue #1686386. Thanks to Thomas Herve for taking an initial stab at coming up with a solution.
* Add a bunch of GIL release/acquire points in tp_print implementations and forBrett Cannon2007-09-171-2/+10
| | | | | | PyObject_Print(). Closes issue #1164.
* Improve extended slicing support in builtin types and classes. Specifically:Thomas Wouters2007-08-281-0/+6
| | | | | | | | | | | | | | | | | | | | - Specialcase extended slices that amount to a shallow copy the same way as is done for simple slices, in the tuple, string and unicode case. - Specialcase step-1 extended slices to optimize the common case for all involved types. - For lists, allow extended slice assignment of differing lengths as long as the step is 1. (Previously, 'l[:2:1] = []' failed even though 'l[:2] = []' and 'l[:2:None] = []' do not.) - Implement extended slicing for buffer, array, structseq, mmap and UserString.UserString. - Implement slice-object support (but not non-step-1 slice assignment) for UserString.MutableString. - Add tests for all new functionality.
* PEP 3123: Provide forward compatibility with Python 3.0, while keepingMartin v. Löwis2007-07-211-40/+38
| | | | | backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and PyVarObject_HEAD_INIT.
* Variation of patch # 1624059 to speed up checking if an object is a subclassNeal Norwitz2007-02-251-1/+1
| | | | | | | | | | | | | | | | | | of some of the common builtin types. Use a bit in tp_flags for each common builtin type. Check the bit to determine if any instance is a subclass of these common types. The check avoids a function call and O(n) search of the base classes. The check is done in the various Py*_Check macros rather than calling PyType_IsSubtype(). All the bits are set in tp_flags when the type is declared in the Objects/*object.c files because PyType_Ready() is not called for all the types. Should PyType_Ready() be called for all types? If so and the change is made, the changes to the Objects/*object.c files can be reverted (remove setting the tp_flags). Objects/typeobject.c would also have to be modified to add conditions for Py*_CheckExact() in addition to each the PyType_IsSubtype check.
* Patch [ 1586791 ] better error msgs for some TypeErrorsGeorg Brandl2006-11-191-2/+3
|
* Patch #1538606, Patch to fix __index__() clipping.Neal Norwitz2006-08-121-5/+2
| | | | | | | I modified this patch some by fixing style, some error checking, and adding XXX comments. This patch requires review and some changes are to be expected. I'm checking in now to get the greatest possible review and establish a baseline for moving forward. I don't want this to hold up release if possible.
* Use Py_VISIT in all tp_traverse methods, instead of traversing manually orThomas Wouters2006-04-151-13/+5
| | | | | | | | using a custom, nearly-identical macro. This probably changes how some of these functions are compiled, which may result in fractionally slower (or faster) execution. Considering the nature of traversal, visiting much of the address space in unpredictable patterns, I'd argue the code readability and maintainability is well worth it ;P
* Remove "static forward" declaration. Move constructorsMartin v. Löwis2006-04-111-21/+19
| | | | after the type objects.
* More low-hanging fruit. Still need to re-arrange some code (or find a betterAnthony Baxter2006-04-111-5/+5
| | | | | solution) in the same way as listobject.c got changed. Hoping for a better solution.
* Fix some missing checks after PyTuple_New, PyList_New, PyDict_NewGeorg Brandl2006-03-171-0/+1
|
* Checking in the code for PEP 357.Guido van Rossum2006-03-071-2/+5
| | | | | | This was mostly written by Travis Oliphant. I've inspected it all; Neal Norwitz and MvL have also looked at it (in an earlier incarnation).
* 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!
generated by cgit v0.12 at 2025-10-18 16:22:57 (GMT)