summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* use Py_UNICODE_WIDE instead of USE_UCS4_STORAGE and Py_UNICODE_SIZEFredrik Lundh2001-06-272-7/+7
| | | | tests.
* Encode surrogates in UTF-8 even for a wide Py_UNICODE.Martin v. Löwis2001-06-272-15/+39
| | | | | | | Implement sys.maxunicode. Explicitly wrap around upper/lower computations for wide Py_UNICODE. When decoding large characters with UTF-8, represent expected test results using the \U notation.
* When decoding UTF-16, don't assume that the buffer is in native endiannessMartin v. Löwis2001-06-261-4/+4
| | | | when checking surrogates.
* Support using UCS-4 as the Py_UNICODE type:Martin v. Löwis2001-06-261-30/+89
| | | | | | | | | | Add configure option --enable-unicode. Add config.h macros Py_USING_UNICODE, PY_UNICODE_TYPE, Py_UNICODE_SIZE, SIZEOF_WCHAR_T. Define Py_UCS2. Encode and decode large UTF-8 characters into single Py_UNICODE values for wide Unicode types; likewise for UTF-16. Remove test whether sizeof Py_UNICODE is two.
* more unicode tweaks: fix unicodectype for sizeof(Py_UNICODE) >Fredrik Lundh2001-06-261-2/+3
| | | | sizeof(int)
* dict_update(): Generalize this method so {}.update() accepts anyBarry Warsaw2001-06-261-17/+70
| | | | | | | | | | | | | | | "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
* experimental UCS-4 support: added USE_UCS4_STORAGE define toFredrik Lundh2001-06-261-0/+2
| | | | | | unicodeobject.h, which forces sizeof(Py_UNICODE) == sizeof(Py_UCS4). (this may be good enough for platforms that doesn't have a 16-bit type. the UTF-16 codecs don't work, though)
* experimental UCS-4 support: made compare a bit more robust, in caseFredrik Lundh2001-06-261-11/+14
| | | | | sizeof(Py_UNICODE) >= sizeof(long). also changed surrogate expansion to work if sizeof(Py_UNICODE) > 2.
* experimental UCS-4 support: don't assume that MS_WIN32 impliesFredrik Lundh2001-06-261-2/+2
| | | | HAVE_USABLE_WCHAR_T
* PyFrameObject: rename f_stackbottom to f_stacktop, since it points toTim Peters2001-06-231-3/+5
| | | | | | | | the next free valuestack slot, not to the base (in America, stacks push and pop at the top -- they mutate at the bottom in Australia <winK>). eval_frame(): assert that f_stacktop isn't NULL upon entry. frame_delloc(): avoid ordered pointer comparisons involving f_stacktop when f_stacktop is NULL.
* Merging the gen-branch into the main line, at Guido's direction. Yay!Tim Peters2001-06-181-0/+6
| | | | | Bugfix candidate in inspect.py: it was referencing "self" outside of a method.
* SF bug 434186: 0x80000000/2 != 0x80000000>>1Tim Peters2001-06-181-23/+17
| | | | | | | | | i_divmod: New and simpler algorithm. Old one returned gibberish on most boxes when the numerator was -sys.maxint-1. Oddly enough, it worked in the release (not debug) build on Windows, because the compiler optimized away some tricky sign manipulations that were incorrect in this case. Makes you wonder <wink> ... Bugfix candidate.
* PyLong_{As, From}VoidPtr: cleanup, replacing assumptions in comments withTim Peters2001-06-161-15/+23
| | | | #if/#error constructs.
* dict_repr: Reuse one of the int vars (minor code simplification).Tim Peters2001-06-161-3/+3
|
* Reformat decl of new _PyString_Join. Add NEWS blurb about repr() speedup.Tim Peters2001-06-161-1/+2
|
* SF bug 433228: repr(list) woes when len(list) big.Tim Peters2001-06-164-56/+189
| | | | | | | | | | | | 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.
* Change IS_LITTLE_ENDIAN macro -- a little faster now.Tim Peters2001-06-141-1/+1
|
* Fix a mis-indentation in _PyUnicode_New() that caused me to stare atGuido van Rossum2001-06-141-3/+3
| | | | some code for longer than needed.
* _PyLong_AsByteArray: simplify the logic for dealing with the most-Tim Peters2001-06-141-11/+13
| | | | significant digits sign bits. Again no change in semantics.
* PyLong_From{Unsigned,}Long: count the # of digits first, so no more spaceTim Peters2001-06-141-21/+41
| | | | | | is allocated than needed (used to allocate 80 bytes of digit space no matter how small the long input). This also runs faster, at least on 32- bit boxes.
* _PyLong_FromByteArray: changed decl of "carry" to match "thisbyte". NoTim Peters2001-06-131-1/+1
| | | | | semantic change, but a bit clearer and may help a really stupid compiler avoid pointless runtime length conversions.
* _PyLong_AsByteArray: Don't do the "delicate overflow" check unless it'sTim Peters2001-06-131-9/+18
| | | | truly needed; usually saves a little time, but no change in semantics.
* _PyLong_AsByteArray: added assert that the input is normalized. This isTim Peters2001-06-131-1/+5
| | | | outside the function's control, but is crucial to correct operation.
* PyLong_As{Unsigned,}LongLong: fiddled final result casting.Tim Peters2001-06-131-2/+2
|
* longobject.c:Tim Peters2001-06-131-126/+41
| | | | | | | | | | | Replaced PyLong_{As,From}{Unsigned,}LongLong guts with calls to _PyLong_{As,From}ByteArray. _testcapimodule.c: Added strong tests of PyLong_{As,From}{Unsigned,}LongLong. Fixes SF bug #432552 PyLong_AsLongLong() problems. Possible bugfix candidate, but the fix relies on code added to longobject to support the new q/Q structmodule format codes.
* _PyLong_{As,From}ByteArray: Minor code rearrangement aimed at improvingTim Peters2001-06-121-11/+14
| | | | clarity. Should have no effect visible to callers.
* Fix for bug #432384: Recursion in PyString_AsEncodedString?Marc-André Lemburg2001-06-121-1/+1
|
* Added q/Q standard (x-platform 8-byte ints) mode in struct module.Tim Peters2001-06-121-6/+19
| | | | | | | | | | | | | | This completes the q/Q project. longobject.c _PyLong_AsByteArray: The original code had a gross bug: the most-significant Python digit doesn't necessarily have SHIFT significant bits, and you really need to count how many copies of the sign bit it has else spurious overflow errors result. test_struct.py: This now does exhaustive std q/Q testing at, and on both sides of, all relevant power-of-2 boundaries, both positive and negative. NEWS: Added brief dict news while I was at it.
* Two new private longobject API functions,Tim Peters2001-06-111-0/+213
| | | | | | | | | | _PyLong_FromByteArray _PyLong_AsByteArray Untested and probably buggy -- they compile OK, but nothing calls them yet. Will soon be called by the struct module, to implement x-platform 'q' and 'Q'. If other people have uses for them, we could move them into the public API. See longobject.h for usage details.
* Added a missing cast to the hashfunc initializer.Jack Jansen2001-06-101-1/+1
|
* Patch #424475: Speed-up tp_compare usage, by special-casing the commonMartin v. Löwis2001-06-092-22/+61
| | | | | | case of objects with equal types which support tp_compare. Give type objects a tp_compare function. Also add c<0 tests before a few PyErr_Occurred tests.
* Fixes [ #430986 ] Buglet in PyUnicode_FromUnicode.Marc-André Lemburg2001-06-071-1/+1
|
* Store the mask instead of the size in dictobjects. The mask is moreTim Peters2001-06-041-23/+29
| | | | | | | frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
* lookdict: stop more insane core-dump mutating comparison cases. ShouldTim Peters2001-06-031-6/+31
| | | | | | | be possible to provoke unbounded recursion now, but leaving that to someone else to provoke and repair. Bugfix candidate -- although this is getting harder to backstitch, and the cases it's protecting against are mondo contrived.
* lookdict: Reduce obfuscating code duplication with a judicious goto.Tim Peters2001-06-031-25/+21
| | | | | This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
* Finish the dict->string coredump fix. Need sleep.Tim Peters2001-06-021-1/+1
| | | | Bugfix candidate.
* Coredumpers from Michael Hudson, mutating dicts while printing orTim Peters2001-06-021-7/+19
| | | | | converting to string. Critical bugfix candidate -- if you take this seriously <wink>.
* dict_popitem(): Repaired last-second 2.1 comment, which misidentified theTim Peters2001-06-021-5/+8
| | | | true reason for allocating the tuple before checking the dict size.
* New collision resolution scheme: no polynomials, simpler, faster, lessTim Peters2001-06-021-163/+124
| | | | | | | code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
* fix bogus indentationJeremy Hylton2001-05-291-1/+1
|
* _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-282-6/+5
| | | | _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.
* Implement an old idea of Christian Tismer's: use polynomial divisionTim Peters2001-05-271-18/+72
| | | | | | | | | | | | | | | instead of multiplication to generate the probe sequence. The idea is recorded in Python-Dev for Dec 2000, but that version is prone to rare infinite loops. The value is in getting *all* the bits of the hash code to participate; and, e.g., this speeds up querying every key in a dict with keys [i << 16 for i in range(20000)] by a factor of 500. Should be equally valuable in any bad case where the high-order hash bits were getting ignored. Also wrote up some of the motivations behind Python's ever-more-subtle hash table strategy.
* Change list.extend() error msgs and NEWS to reflect that list.extend()Tim Peters2001-05-261-2/+2
| | | | | | | now takes any iterable argument, not only sequences. NEEDS DOC CHANGES -- but I don't think we settled on a concise way to say this stuff.
* Cruft cleanup: removed the #ifdef'ery in support of compiling to allowTim Peters2001-05-261-18/+4
| | | | multi-argument list.append(1, 2, 3) (as opposed to .append((1,2,3))).
* roundupsize() and friends: fiddle over-allocation strategy for listTim Peters2001-05-261-8/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | resizing. Accurate timings are impossible on my Win98SE box, but this is obviously faster even on this box for reasonable list.append() cases. I give credit for this not to the resizing strategy but to getting rid of integer multiplication and divsion (in favor of shifting) when computing the rounded-up size. For unreasonable list.append() cases, Win98SE now displays linear behavior for one-at-time appends up to a list with about 35 million elements. Then it dies with a MemoryError, due to fatally fragmented *address space* (there's plenty of VM available, but by this point Win9X has broken user space into many distinct heaps none of which has enough contiguous space left to resize the list, and for whatever reason Win9x isn't coalescing the dead heaps). Before the patch it got a MemoryError for the same reason, but once the list reached about 2 million elements. Haven't yet tried on Win2K but have high hopes extreme list.append() will be much better behaved now (NT & Win2K didn't fragment address space, but suffered obvious quadratic-time behavior before as lists got large). For other systems I'm relying on common sense: replacing integer * and / by << and >> can't plausibly hurt, the number of function calls hasn't changed, and the total operation count for reasonably small lists is about the same (while the operations are cheaper now).
* Patch #424335: Implement string_richcompare, remove string_compare.Martin v. Löwis2001-05-242-16/+80
| | | | Use new _PyString_Eq in lookdict_string.
* dictresize(): Rebuild small tables if there are any dummies, not just ifTim Peters2001-05-241-7/+11
| | | | | they're entirely full. Not a question of correctness, but of temporarily misplaced common sense.
* Jack Jansen hit a bug in the new dict code, reported on python-dev.Tim Peters2001-05-231-9/+28
| | | | | | | | | | dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
generated by cgit v0.12 at 2024-12-12 15:37:26 (GMT)