summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* long_pow(): Fix more instances of leaks in error cases.Tim Peters2004-08-301-3/+3
| | | | | Bugfix candidate -- although long_pow() is so different now I doubt a patch would apply to 2.3.
* SF patch 936813: fast modular exponentiationTim Peters2004-08-301-107/+185
| | | | | | | | | | | | | | | | | | | | | | | | This checkin is adapted from part 2 (of 3) of Trevor Perrin's patch set. BACKWARD INCOMPATIBILITY: SHIFT must now be divisible by 5. AFAIK, nobody will care. long_pow() could be complicated to worm around that, if necessary. long_pow(): - BUGFIX: This leaked the base and power when the power was negative (and so the computation delegated to float pow). - Instead of doing right-to-left exponentiation, do left-to-right. This is more efficient for small bases, which is the common case. - In addition, if the exponent is large (more than FIVEARY_CUTOFF digits), precompute [a**i % c for i in range(32)], and go left to right 5 bits at a time. l_divmod(): - The signature changed so that callers who don't want the quotient, or don't want the remainder, can pass NULL in the slot they don't want. This saves them from having to declare a vrbl for unwanted stuff, and remembering to decref it. long_mod(), long_div(), long_classic_div(): - Adjust to new l_divmod() signature, and simplified as a result.
* SF patch 936813: fast modular exponentiationTim Peters2004-08-291-21/+79
| | | | | | | | | | | | | | | | | | This checkin is adapted from part 1 (of 3) of Trevor Perrin's patch set. x_mul() - sped a little by optimizing the C - sped a lot (~2X) if it's doing a square; note that long_pow() squares often k_mul() - more cache-friendly now if it's doing a square KARATSUBA_CUTOFF - boosted; gradeschool mult is quicker now, and it may have been too low for many platforms anyway KARATSUBA_SQUARE_CUTOFF - new - since x_mul is a lot faster at squaring now, the point at which Karatsuba pays for squaring is much higher than for general mult
* PyUnicode_Join(): Bozo Alert. While this is chugging along, it mayTim Peters2004-08-271-0/+12
| | | | | | | | | need to convert str objects from the iterable to unicode. So, if someone set the system default encoding to something nasty enough, the conversion process could mutate the input iterable as a side effect, and PySequence_Fast doesn't hide that from us if the input was a list. IOW, can't assume the size of PySequence_Fast's result is invariant across PyUnicode_FromObject() calls.
* PyUnicode_Join(): Rewrote to use PySequence_Fast(). This doesn't doTim Peters2004-08-271-126/+96
| | | | | | | | much to reduce the size of the code, but greatly improves its clarity. It's also quicker in what's probably the most common case (the argument iterable is a list). Against it, if the iterable isn't a list or a tuple, a temp tuple is materialized containing the entire input sequence, and that's a bigger temp memory burden. Yawn.
* PyUnicode_Join(): Missed a spot where I intended a cast from size_t toTim Peters2004-08-271-1/+1
| | | | | int. I sure wish MS would gripe about that! Whatever, note that the statement above it guarantees that the cast loses no info.
* PyUnicode_Join(): Two primary aims:Tim Peters2004-08-271-40/+120
| | | | | | | | 1. u1.join([u2]) is u2 2. Be more careful about C-level int overflow. Since PySequence_Fast() isn't needed to achieve #1, it's not used -- but the code could sure be simpler if it were.
* Fix docstring typo.Raymond Hettinger2004-08-251-1/+1
|
* Stop producing or using OverflowWarning. PEP 237 thought this wouldTim Peters2004-08-251-36/+4
| | | | | | | happen in 2.3, but nobody noticed it still was getting generated (the warning was disabled by default). OverflowWarning and PyExc_OverflowWarning should be removed for 2.5, and left notes all over saying so.
* SF Patch #1007087: Return new string for single subclass joins (Bug #1001011)Raymond Hettinger2004-08-231-12/+8
| | | | | | | (Patch contributed by Nick Coghlan.) Now joining string subtypes will always return a string. Formerly, if there were only one item, it was returned unchanged.
* Fix repr for negative imaginary part. Fixes #1013908.Martin v. Löwis2004-08-221-2/+6
|
* Patch #980082: Missing INCREF in PyType_Ready.Martin v. Löwis2004-08-181-1/+3
|
* 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
|
generated by cgit v0.12 at 2024-11-27 13:31:08 (GMT)