summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* SF bug #444510: int() should guarantee truncation.Tim Peters2001-07-261-7/+13
| | | | It's guaranteed now, assuming the platform modf() works correctly.
* Fix for bug #444493: u'\U00010001' segfaults with current CVS onMarc-André Lemburg2001-07-251-6/+21
| | | | wide builds.
* Make the unicode-escape and the UTF-16 codecs handle surrogatesMarc-André Lemburg2001-07-201-24/+46
| | | | | | | | correctly and thus roundtrip-safe. Some minor cleanups of the code. Added tests for the roundtrip-safety.
* #ifdef out generation of \U escapes unless Py_UNICODE_WIDE. ThisGuido van Rossum2001-07-201-0/+2
| | | | | | | | | | #caused warnings with the VMS C compiler. (SF bug #442998, in part.) On a narrow system the current code should never be executed since ch will always be < 0x10000. Marc-Andre: you may end up fixing this a different way, since I believe you have plans to generate \U for surrogate pairs. I'll leave that to you.
* Kill more warnings from the SGI compiler.Fred Drake2001-07-192-2/+2
| | | | Part of SF patch #434992.
* Python.h: Don't attempt to redefine NDEBUG if it's already defined.Tim Peters2001-07-151-1/+0
| | | | Others: Remove redundant includes of assert.h.
* long_format: Simplify the overly elaborate base-is-a-power-of-2 code.Tim Peters2001-07-151-28/+16
|
* _Py_GetObjects(): GCC suggests to add () around && within || for someGuido van Rossum2001-07-141-1/+1
| | | | code only compiled in debug mode, and I dutifully comply.
* divrem1 & long_format: found a clean way to factor divrem1 so thatTim Peters2001-07-141-28/+54
| | | | | long_format can reuse a scratch area for its repeated divisions (instead of malloc/free for every digit produced); speeds str(long)/repr(long).
* long_format(): Simplify new code a bit.Tim Peters2001-07-141-5/+8
|
* long_format(): Easy speedup for output bases that aren't a power of 2 (inTim Peters2001-07-131-9/+26
| | | | | | | particular, str(long) and repr(long) use base 10, and that gets a factor of 4 speedup). Another factor of 2 can be gotten by refactoring divrem1 to support in-place division, but that started getting messy so I'm leaving that out.
* GC for method objects.Neil Schemenauer2001-07-121-11/+31
|
* GC for iterator objects.Neil Schemenauer2001-07-121-6/+29
|
* GC for frame objects.Neil Schemenauer2001-07-121-12/+101
|
* On long to the negative long power, let float handle it instead ofGuido van Rossum2001-07-121-8/+7
| | | | | | raising an error. This was one of the two issues that the VPython folks were particularly problematic for their students. (The other one was integer division...) This implements (my) SF patch #440487.
* On int to the negative integral power, let float handle it instead ofGuido van Rossum2001-07-121-7/+5
| | | | | | raising an error. This was one of the two issues that the VPython folks were particularly problematic for their students. (The other one was integer division...) This implements (my) SF patch #440487.
* Re-add 'advanced' xrange features, adding DeprecationWarnings as discussedThomas Wouters2001-07-091-16/+219
| | | | | on python-dev. The features will still vanish, however, just one release later.
* SF bug #439104: Tuple richcompares has code-typo.Tim Peters2001-07-061-1/+1
| | | | | | Symptom: (1, 2, 3) <= (1, 2) returned 1. This was already fixed in CVS for tuples, but an isomorphic error was in the list richcompare code.
* Rip out the fancy behaviors of xrange that nobody uses: repeat, slice,Guido van Rossum2001-07-051-222/+15
| | | | | contains, tolist(), and the start/stop/step attributes. This includes removing the 4th ('repeat') argument to PyRange_New().
* removed "register const" from scalar arguments to the unicodeFredrik Lundh2001-06-271-20/+20
| | | | predicates
* 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
|