summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* SF patch #1005778, Fix seg fault if list object is modified during list.index()Neal Norwitz2004-08-131-3/+1
| | | | Backport candidate
* This is my patchMichael W. Hudson2004-08-121-4/+32
| | | | | | | [ 1004703 ] Make func_name writable plus fixing a couple of nits in the documentation changes spotted by MvL and a Misc/NEWS entry.
* Previous commit was viewed as "perverse". Changed to just cast the unusedBrett Cannon2004-08-081-1/+3
| | | | | | variable to void.. Thanks to Sjoerd Mullender for the suggested change.
* Bug 1003935: xrange overflowsTim Peters2004-08-081-1/+16
| | | | | | | | | | | | | | | Added XXX comment about why the undocumented PyRange_New() API function is too broken to be worth the considerable pain of repairing. Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Nothing in the core uses PyRange_New() now. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised.
* Trimmed trailing whitespace.Tim Peters2004-08-081-5/+5
|
* This was quite a dark bug in my recent in-place string concatenationArmin Rigo2004-08-071-1/+2
| | | | | | hack: it would resize *interned* strings in-place! This occurred because their reference counts do not have their expected value -- stringobject.c hacks them. Mea culpa.
* Fixed some compiler warnings.Armin Rigo2004-08-071-2/+2
|
* Subclasses of string can no longer be interned. The semantics ofJeremy Hylton2004-08-071-22/+12
| | | | | | | | | | | interning were not clear here -- a subclass could be mutable, for example -- and had bugs. Explicitly interning a subclass of string via intern() will raise a TypeError. Internal operations that attempt to intern a string subclass will have no effect. Added a few tests to test_builtin that includes the old buggy code and verifies that calls like PyObject_SetAttr() don't fail. Perhaps these tests should have gone in test_string.
* SF bug #1004669: Type returned from .keys() is not checkedRaymond Hettinger2004-08-071-0/+5
|
* SF #989185: Drop unicode.iswide() and unicode.width() and addHye-Shik Chang2004-08-043-437/+299
| | | | | | | | | | | | unicodedata.east_asian_width(). You can still implement your own simple width() function using it like this: def width(u): w = 0 for c in unicodedata.normalize('NFC', u): cwidth = unicodedata.east_asian_width(c) if cwidth in ('W', 'F'): w += 2 else: w += 1 return w
* Be more careful about maintaining the invariants; it was actuallyFred Drake2004-08-031-3/+25
| | | | | possible that the callback-less flavors of the ref or proxy could have been added during GC, so we don't want to replace them.
* Repair the same thinko in two places about handling of _Py_RefTotal inMichael W. Hudson2004-08-032-10/+12
| | | | | | | the case of __del__ resurrecting an object. This makes the apparent reference leaks in test_descr go away (which I expected) and also kills off those in test_gc (which is more surprising but less so once you actually think about it a bit).
* Tweak previous patch to silence a warning about the unused left value in theBrett Cannon2004-08-031-1/+1
| | | | | | comma expression in listpop() that was being returned. Still essentially unused (as it is meant to be), but now the compiler thinks it is worth *something* by having it incremented.
* Add a missing decref.Michael W. Hudson2004-08-021-0/+1
|
* list_ass_slice(): Document the obscure new intent that deleting a sliceTim Peters2004-07-311-8/+16
| | | | | | | | | | | | | | | | | | | | | of no more than 8 elements cannot fail. listpop(): Take advantage of that its calls to list_resize() and list_ass_slice() can't fail. This is assert'ed in a debug build now, but in an icky way. That is, you can't say: assert(some_call() >= 0); because then some_call() won't occur at all in a release build. So it has to be a big pile of #ifdefs on Py_DEBUG (yuck), or the pleasant: status = some_call(); assert(status >= 0); But in that case, compilers may whine in a release build, because status appears unused then. I'm not certain the ugly trick I used here will convince all compilers to shut up about status (status is always "used" now, as the first (ignored) clause in a comma expression).
* list_ass_slice(): The difference between "recycle" and "recycled" wasTim Peters2004-07-311-17/+10
| | | | | | | | impossible to remember, so renamed one to something obvious. Headed off potential signed-vs-unsigned compiler complaints I introduced by changing the type of a vrbl to unsigned. Removed the need for the tedious explanation about "backward pointer loops" by looping on an int instead.
* Armin asked for a list_ass_slice review in his checkin, so here's theTim Peters2004-07-311-26/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | result. list_resize(): Document the intent. Code is increasingly relying on subtle aspects of its behavior, and they deserve to be spelled out. list_ass_slice(): A bit more simplification, by giving it a common error exit and initializing more values. Be clearer in comments about what "size" means (# of elements? # of bytes?). While the number of elements in a list slice must fit in an int, there's no guarantee that the number of bytes occupied by the slice will. That malloc() and memmove() take size_t arguments is a hint about that <wink>. So changed to use size_t where appropriate. ihigh - ilow should always be >= 0, but we never asserted that. We do now. The loop decref'ing the recycled slice had a subtle insecurity: C doesn't guarantee that a pointer one slot *before* an array will compare "less than" to a pointer within the array (it does guarantee that a pointer one beyond the end of the array compares as expected). This was actually an issue in KSR's C implementation, so isn't purely theoretical. Python probably has other "go backwards" loops with a similar glitch. list_clear() is OK (it marches an integer backwards, not a pointer).
* This is a reorganization of list_ass_slice(). It should probably be reviewed,Armin Rigo2004-07-301-22/+20
| | | | | | | | | | | | | | | though I tried to be very careful. This is a slight simplification, and it adds a new feature: a small stack-allocated "recycled" array for the cases when we don't remove too many items. It allows PyList_SetSlice() to never fail if: * you are sure that the object is a list; and * you either do not remove more than 8 items, or clear the list. This makes a number of other places in the source code correct again -- there are some places that delete a single item without checking for MemoryErrors raised by PyList_SetSlice(), or that clear the whole list, and sometimes the context doesn't allow an error to be propagated.
* What if you call lst.__init__() while it is being sorted? :-)Armin Rigo2004-07-301-2/+4
| | | | The invariant checks would break.
* * Simplify and speed-up list_resize(). Relying on the newly documentedRaymond Hettinger2004-07-291-3/+7
| | | | | | | | | invariants allows the ob_item != NULL check to be replaced with an assertion. * Added assertions to list_init() which document and verify that the tp_new slot establishes the invariants. This may preclude a future bug if a custom tp_new slot is written.
* * drop the unreasonable list invariant that ob_item should never come backArmin Rigo2004-07-291-28/+46
| | | | | | | | | | | | | | | | | | | | | to NULL during the lifetime of the object. * listobject.c nevertheless did not conform to the other invariants, either; fixed. * listobject.c now uses list_clear() as the obvious internal way to clear a list, instead of abusing list_ass_slice() for that. It makes it easier to enforce the invariant about ob_item == NULL. * listsort() sets allocated to -1 during sort; any mutation will set it to a value >= 0, so it is a safe way to detect mutation. A negative value for allocated does not cause a problem elsewhere currently. test_sort.py has a new test for this fix. * listsort() leak: if items were added to the list during the sort, AND if these items had a __del__ that puts still more stuff into the list, then this more stuff (and the PyObject** array to hold them) were overridden at the end of listsort() and never released.
* Minor memory leak.Armin Rigo2004-07-291-0/+2
|
* Fix obscure breakage (relative to 2.3) in listsort: the test for listTim Peters2004-07-291-26/+12
| | | | | | | | | | | | mutation during list.sort() used to rely on that listobject.c always NULL'ed ob_item when ob_size fell to 0. That's no longer true, so the test for list mutation during a sort is no longer reliable. Changed the test to rely instead on that listobject.c now never NULLs-out ob_item after (if ever) ob_item gets a non-NULL value. This new assumption is also documented now, as a required invariant in listobject.h. The new assumption allowed some real simplification to some of the hairier code in listsort(), so is a Good Thing on that count.
* Trimmed trailing whitespace.Tim Peters2004-07-291-21/+21
|
* PyList_New(): we went to all the trouble of computing and bounds-checkingTim Peters2004-07-291-1/+2
| | | | | the size_t nbytes, and passed nbytes to malloc, so it was confusing to effectively recompute the same thing from scratch in the memset call.
* Let u'%s' % obj try obj.__unicode__() first and fallback to obj.__str__().Marc-André Lemburg2004-07-231-10/+12
|
* Check the type of values returned by __int__, __float__, __long__,Neil Schemenauer2004-07-192-12/+33
| | | | | | __oct__, and __hex__. Raise TypeError if an invalid type is returned. Note that PyNumber_Int and PyNumber_Long can still return ints or longs. Fixes SF bug #966618.
* Moved SunPro warning suppression into pyport.h and out of individualNicholas Bastin2004-07-154-16/+0
| | | | modules and objects.
* Fix a copy&paste typo.Marc-André Lemburg2004-07-101-1/+1
|
* .encode()/.decode() patch part 2.Marc-André Lemburg2004-07-082-0/+20
|
* Allow string and unicode return types from .encode()/.decode()Marc-André Lemburg2004-07-082-7/+119
| | | | | methods on string and unicode objects. Added unicode.decode() which was missing for no apparent reason.
* Fix a couple of signed/unsigned comparison warningsNeal Norwitz2004-07-081-1/+1
|
* Remove unused macros in .c filesNeal Norwitz2004-07-082-4/+0
|
* SF bug #978308, Spurious errors taking bool of dead proNeal Norwitz2004-07-081-1/+1
| | | | | | Need to return -1 on error. Needs backport.
* Make weak references subclassable:Fred Drake2004-07-022-68/+183
| | | | | | | | | | | | | | | | | | | | | | - weakref.ref and weakref.ReferenceType will become aliases for each other - weakref.ref will be a modern, new-style class with proper __new__ and __init__ methods - weakref.WeakValueDictionary will have a lighter memory footprint, using a new weakref.ref subclass to associate the key with the value, allowing us to have only a single object of overhead for each dictionary entry (currently, there are 3 objects of overhead per entry: a weakref to the value, a weakref to the dictionary, and a function object used as a weakref callback; the weakref to the dictionary could be avoided without this change) - a new macro, PyWeakref_CheckRefExact(), will be added - PyWeakref_CheckRef() will check for subclasses of weakref.ref This closes SF patch #983019.
* SF Bug #215126: Over restricted type checking on eval() functionRaymond Hettinger2004-07-022-7/+10
| | | | | | The builtin eval() function now accepts any mapping for the locals argument. Time sensitive steps guarded by PyDict_CheckExact() to keep from slowing down the normal case. My timings so no measurable impact.
* sizeof(char) is 1, by definition, so get rid of that expression inTim Peters2004-06-271-12/+7
| | | | places it's just noise.
* Patch #966493: Cleanup generator/eval_frame exposure.Martin v. Löwis2004-06-271-1/+1
|
* SF bug #980419: int left-shift causes memory leakRaymond Hettinger2004-06-261-4/+26
|
* Cosmetic spacing fix.Raymond Hettinger2004-06-251-1/+1
|
* Fix leak found by Eric Huss.Raymond Hettinger2004-06-251-1/+6
|
* Disabling end-of-loop code not reached warning on SunProNicholas Bastin2004-06-181-0/+4
|
* Fixed end-of-loop code not reached warning when using SunPro CNicholas Bastin2004-06-173-0/+12
|
* Remove a function no longer in use.Raymond Hettinger2004-06-141-8/+0
|
* Remove unnecessary GC support. Sets cannot have cycles.Raymond Hettinger2004-06-131-16/+7
|
* * Factor out PyObject_SelfIter().Raymond Hettinger2004-06-121-9/+3
| | | | * Change a XDECREF to DECREF (adding an assertion just to be sure).
* Fix for bug #966623 - classes created with type() in an exec(, {}) don'tAnthony Baxter2004-06-111-0/+4
| | | | | | have a __module__. Test for this case. Bugfix candidate, will backport.
* dump HAVE_FOPENRF stuff - obsoleteSkip Montanaro2004-06-111-26/+19
|
* Futher improvements to frozenset hashing (based on Yitz Gale's battery ofRaymond Hettinger2004-06-101-8/+10
| | | | | | | | | | | | | tests which nicely highly highlight weaknesses). * Initial value is now a large prime. * Pre-multiply by the set length to add one more basis of differentiation. * Work a bit harder inside the loop to scatter bits from sources that may have closely spaced hash values. All of this is necessary to make up for keep the hash function commutative. Fortunately, the hash value is cached so the call to frozenset_hash() will only occur once per set.
* Fixups to the hash function for frozensets.Raymond Hettinger2004-06-101-1/+4
| | | | | | * Non-zero initial value so that hash(frozenset()) != hash(0). * Final permutation to differentiate nested sets. * Add logic to make sure that -1 is not a possible hash value.
generated by cgit v0.12 at 2024-11-29 19:33:57 (GMT)