summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* Check whether a string resize is necessary at the endWalter Dörwald2002-09-031-3/+4
| | | | | | | | | of PyString_DecodeEscape(). This prevents a call to _PyString_Resize() for the empty string, which would result in a PyErr_BadInternalCall(), because the empty string has more than one reference. This closes SF bug http://www.python.org/sf/603937
* PEP 293 implemention (from SF patch http://www.python.org/sf/432401)Walter Dörwald2002-09-022-554/+1246
|
* Added comparison functions to dict proxies.Raymond Hettinger2002-08-311-2/+14
| | | | | Now all non-mutating dict methods are in the proxy also. Inspired by SF bug #602232,
* SF #561244: micro optimizations, builtins cannot be NULL, so use Py_INCREFNeal Norwitz2002-08-291-1/+1
|
* complex() was the only numeric constructor that created a new instanceRaymond Hettinger2002-08-291-0/+9
| | | | when given its own type as an argument.
* string_contains(): speed up by avoiding function calls whereGuido van Rossum2002-08-241-9/+12
| | | | | | possible. This always called PyUnicode_Check() and PyString_Check(), at least one of which would call PyType_IsSubtype(). Also, this would call PyString_Size() on known string objects.
* Speedup for PyObject_IsTrue(): check for True and False first.Guido van Rossum2002-08-241-0/+4
| | | | | Because all built-in tests return bools now, this is the most common path!
* Speedup for PyObject_RichCompareBool(): PyObject_RichCompare() almostGuido van Rossum2002-08-241-1/+4
| | | | | always returns a bool, so avoid calling PyObject_IsTrue() in that case.
* Fix SF bug 599128, submitted by Inyeol Lee: .replace() would do theGuido van Rossum2002-08-231-3/+9
| | | | | | | | | | | | | wrong thing for a unicode subclass when there were zero string replacements. The example given in the SF bug report was only one way to trigger this; replacing a string of length >= 2 that's not found is another. The code would actually write outside allocated memory if replacement string was longer than the search string. (I wonder how many more of these are lurking? The unicode code base is full of wonders.) Bugfix candidate; this same bug is present in 2.2.1.
* Code by Inyeol Lee, submitted to SF bug 595350, to implementGuido van Rossum2002-08-232-38/+53
| | | | | the string/unicode method .replace() with a zero-lengt first argument. Inyeol contributed tests for this too.
* long_format(), long_lshift(): Someone on c.l.py is trying to boostTim Peters2002-08-201-2/+2
| | | | | | | | | | | | SHIFT and MASK, and widen digit. One problem is that code of the form digit << small_integer implicitly assumes that the result fits in an int or unsigned int (platform-dependent, but "int sized" in any case), since digit is promoted "just" to int or unsigned via the usual integer promotions. But if digit is typedef'ed as unsigned int, this loses information. The cure for this is just to cast digit to twodigits first.
* Fix some endcase bugs in unicode rfind()/rindex() and endswith().Guido van Rossum2002-08-202-4/+4
| | | | | | These were reported and fixed by Inyeol Lee in SF bug 595350. The endswith() bug was already fixed in 2.3, but this adds some more test cases.
* getinstclassname(): Squash new compiler wng in assert (comparison ofTim Peters2002-08-201-1/+1
| | | | signed vs unsigned).
* SF patch 576101, by Oren Tirosh: alternative implementation ofGuido van Rossum2002-08-193-100/+135
| | | | | | | | interning. I modified Oren's patch significantly, but the basic idea and most of the implementation is unchanged. Interned strings created with PyString_InternInPlace() are now mortal, and you must keep a reference to the resulting string around; use the new function PyString_InternImmortal() to create immortal interned strings.
* Call me anal, but there was a particular phrase that was speading toGuido van Rossum2002-08-196-8/+8
| | | | | | | 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.
* Another modest speedup in PyObject_GenericGetAttr(): inline the callGuido van Rossum2002-08-191-2/+26
| | | | to _PyType_Lookup().
* Make PyDescr_IsData() a macro. It's too simple to be a function.Guido van Rossum2002-08-191-6/+0
| | | | Should save 4% on slot lookups.
* Check in my ultra-shortlived patch #597220.Michael W. Hudson2002-08-191-3/+3
| | | | | | Move some debugging checks inside Py_DEBUG. They were causing cache misses according to cachegrind.
* Inline call to _PyObject_GetDictPtr() in PyObject_GenericGetAttr().Guido van Rossum2002-08-191-3/+20
| | | | This causes a modest speedup.
* Simple but important optimization for descr_check(): instead of theGuido van Rossum2002-08-191-1/+1
| | | | | | | expensive and overly general PyObject_IsInstance(), call PyObject_TypeCheck() which is a macro that often avoids a call, and if it does make a call, calls the much more efficient PyType_IsSubtype(). This saved 6% on a benchmark for slot lookups.
* Get this to compile again if Py_USING_UNICODE is not defined.Neal Norwitz2002-08-161-1/+1
| | | | com_error() is static in Python/compile.c.
* Squash a few calls to the hideously expensive PyObject_CallObject(o,a)Guido van Rossum2002-08-163-8/+22
| | | | | | | -- replace then with slightly faster PyObject_Call(o,a,NULL). (The difference is that the latter requires a to be a tuple; the former allows other values and wraps them in a tuple if necessary; it involves two more levels of C function calls to accomplish all that.)
* Fix SF bug 595838 -- buffer in type_new() should not be static. MovedGuido van Rossum2002-08-161-1/+1
| | | | to inner scope, too.
* Illustrating by example one good reason not to trust a proof <wink>.Tim Peters2002-08-151-3/+3
|
* k_mul() comments: In honor of Dijkstra, made the proof that "t3 fits"Tim Peters2002-08-151-34/+37
| | | | | | | rigorous instead of hoping for testing not to turn up counterexamples. Call me heretical, but despite that I'm wholly confident in the proof, and have done it two different ways now, I still put more faith in testing ...
* long_mul(): Simplified exit code. In particular, k_mul() returns aTim Peters2002-08-151-9/+3
| | | | | normalized result, so no point to normalizing it again. The number of test+branches was also excessive.
* This is my patchMichael W. Hudson2002-08-151-2/+12
| | | | | | | | [ 587993 ] SET_LINENO killer Remove SET_LINENO. Tracing is now supported by inspecting co_lnotab. Many sundry changes to document and adapt to this change.
* Reflow long lines.Jeremy Hylton2002-08-141-26/+32
|
* More changes of DeprecationWarning to FutureWarning.Guido van Rossum2002-08-143-6/+6
|
* PyType_Ready(): initialize the base class a bit earlier, so that if weGuido van Rossum2002-08-141-6/+6
| | | | copy the metatype from the base, the base actually has one!
* k_mul() comments: Simplified the simplified explanation of why ah*bh andTim Peters2002-08-141-6/+3
| | | | al*bl "always fit": it's actually trivial given what came before.
* k_mul() comments: Explained why there's always enough room to subtractTim Peters2002-08-141-0/+7
| | | | | | ah*bh and al*bl. This is much easier than explaining why that's true for (ah+al)*(bh+bl), and follows directly from the simple part of the (ah+al)*(bh+bl) explanation.
* Check for trailing backslash. Fixes #593656.Martin v. Löwis2002-08-141-5/+8
|
* Patch #505705: Remove eval in pickle and cPickle.Martin v. Löwis2002-08-141-3/+157
|
* Allow more docstrings to be removed during compilationNeal Norwitz2002-08-132-14/+18
|
* Fixed error in new comment.Tim Peters2002-08-131-4/+3
|
* k_mul(): The fix for (ah+al)*(bh+bl) spilling 1 bit beyond the allocatedTim Peters2002-08-131-8/+44
| | | | | | | | | | space is no longer needed, so removed the code. It was only possible when a degenerate (ah->ob_size == 0) split happened, but after that fix went in I added k_lopsided_mul(), which saves the body of k_mul() from seeing a degenerate split. So this removes code, and adds a honking long comment block explaining why spilling out of bounds isn't possible anymore. Note: ff we end up spilling out of bounds anyway <wink>, an assert in v_iadd() is certain to trigger.
* Allow docstrings to be removed during compilation for *SLOT macro and friendsNeal Norwitz2002-08-131-3/+5
|
* Allow docstrings to be removed during compilationNeal Norwitz2002-08-131-3/+3
|
* Add an improvement wrinkle to Neil Schemenauer's change to int_mulGuido van Rossum2002-08-131-2/+4
| | | | | | | (rev. 2.86). The other type is only disqualified from sq_repeat when it has the CHECKTYPES flag. This means that for extension types that only support "old-style" numeric ops, such as Zope 2's ExtensionClass, sq_repeat still trumps nb_multiply.
* Fix comment for PyLong_AsUnsignedLong() to say that the return valueGuido van Rossum2002-08-131-1/+1
| | | | is an *unsigned* long.
* k_lopsided_mul(): This allocated more space for bslice than necessary.Tim Peters2002-08-121-1/+1
|
* Added new function k_lopsided_mul(), which is much more efficient thanTim Peters2002-08-121-10/+72
| | | | | | | | k_mul() when inputs have vastly different sizes, and a little more efficient when they're close to a factor of 2 out of whack. I consider this done now, although I'll set up some more correctness tests to run overnight.
* k_mul(): Moved an assert down. In a debug build, interrupting aTim Peters2002-08-121-2/+2
| | | | | multiply via Ctrl+C could cause a NULL-pointer dereference due to the assert.
* k_mul(): Heh -- I checked in two fixes for the last problem. Only keepTim Peters2002-08-121-2/+2
| | | | the good one <wink>. Also checked in a test-aid by mistake.
* k_mul(): White-box testing turned up that (ah+al)*(bh+bl) can, in rareTim Peters2002-08-121-3/+11
| | | | | | | | | cases, overflow the allocated result object by 1 bit. In such cases, it would have been brought back into range if we subtracted al*bl and ah*bh from it first, but I don't want to do that because it hurts cache behavior. Instead we just ignore the excess bit when it appears -- in effect, this is forcing unsigned mod BASE**(asize + bsize) arithmetic in a case where that doesn't happen all by itself.
* Fix MSVC warnings.Guido van Rossum2002-08-121-2/+2
|
* Refactor how __dict__ and __weakref__ interact with __slots__.Guido van Rossum2002-08-121-55/+147
| | | | | | | | | | | | | | | | | | | | | | | 1. You can now have __dict__ and/or __weakref__ in your __slots__ (before only __weakref__ was supported). This is treated differently than before: it merely sets a flag that the object should support the corresponding magic. 2. Dynamic types now always have descriptors __dict__ and __weakref__ thrust upon them. If the type in fact does not support one or the other, that descriptor's __get__ method will raise AttributeError. 3. (This is the reason for all this; it fixes SF bug 575229, reported by Cesar Douady.) Given this code: class A(object): __slots__ = [] class B(object): pass class C(A, B): __slots__ = [] the class object for C was broken; its size was less than that of B, and some descriptors on B could cause a segfault. C now correctly inherits __weakrefs__ and __dict__ from B, even though A is the "primary" base (C.__base__ is A). 4. Some code cleanup, and a few comments added.
* x_mul(): Made life easier for C optimizers in the "grade school"Tim Peters2002-08-121-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | algorithm. MSVC 6 wasn't impressed <wink>. Something odd: the x_mul algorithm appears to get substantially worse than quadratic time as the inputs grow larger: bits in each input x_mul time k_mul time ------------------ ---------- ---------- 15360 0.01 0.00 30720 0.04 0.01 61440 0.16 0.04 122880 0.64 0.14 245760 2.56 0.40 491520 10.76 1.23 983040 71.28 3.69 1966080 459.31 11.07 That is, x_mul is perfectly quadratic-time until a little burp at 2.56->10.76, and after that goes to hell in a hurry. Under Karatsuba, doubling the input size "should take" 3 times longer instead of 4, and that remains the case throughout this range. I conclude that my "be nice to the cache" reworkings of k_mul() are paying.
* k_mul() and long_mul(): I'm confident that the Karatsuba algorithm isTim Peters2002-08-121-9/+30
| | | | | | | | correct now, so added some final comments, did some cleanup, and enabled it for all long-int multiplies. The KARAT envar no longer matters, although I left some #if 0'ed code in there for my own use (temporary). k_mul() is still much slower than x_mul() if the inputs have very differenent sizes, and that still needs to be addressed.
generated by cgit v0.12 at 2024-11-29 09:56:14 (GMT)