summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* Remove much dead code from ceval.cJeremy Hylton2001-08-121-35/+35
| | | | | | | | | | | | | | The descr changes moved the dispatch for calling objects from call_object() in ceval.c to PyObject_Call() in abstract.c. call_object() and the many functions it used in ceval.c were no longer used, but were not removed. Rename meth_call() as PyCFunction_Call() so that it can be called by the CALL_FUNCTION opcode in ceval.c. Also, fix error message that referred to PyEval_EvalCodeEx() by its old name eval_code2(). (I'll probably refer to it by its old name, too.)
* Make dynamic types work as intended. Or at least more so.Guido van Rossum2001-08-121-22/+35
| | | | | | | XXX There are still some loose ends: repr(), str(), hash() and comparisons don't inherit a default implementation from object. This must be resolved similarly to the way it's resolved for classic instances.
* Temporary stop-gap fix for dynamic classes, so they pass the test.Guido van Rossum2001-08-121-1/+6
| | | | | | | | | | XXX This is not sufficient: if a dynamic class has no __repr__ method (for instance), but later one is added, that doesn't add a tp_repr slot, so repr() doesn't call the __repr__ method. To make this work, I'll have to add default implementations of several slots to 'object'. XXX Also, dynamic types currently only inherit slots from their dominant base.
* - Big changes to fix SF bug #442833 (a nasty multiple inheritanceGuido van Rossum2001-08-101-91/+122
| | | | | | | | | | | | | | | | problem). inherit_slots() is split in two parts: inherit_special() which inherits the flags and a few very special members from the dominant base; inherit_slots() which inherits only regular slots, and is now called for each base in the MRO in turn. These are now both void functions since they don't have error returns. - Added object.__setitem__() back -- for the same reason as object.__new__(): a subclass of object should be able to call object.__new__(). - add_wrappers() was moved around to be closer to where it is used (it was defined together with add_methods() etc., but has nothing to do with these).
* Add PyDict_Merge(a, b, override):Guido van Rossum2001-08-101-2/+18
| | | | | | PyDict_Merge(a, b, 1) is the same as PyDict_Update(a, b). PyDict_Merge(a, b, 0) does something similar but leaves existing items unchanged.
* Change PyType_Ready() to use the READY and READYING flags. This makesGuido van Rossum2001-08-101-13/+26
| | | | | it possible to detect recursive calls early (as opposed to when the stack overflows :-).
* SF patch #438013 Remove 2-byte Py_UCS2 assumptionsTim Peters2001-08-091-76/+90
| | | | | | | | Removed all instances of Py_UCS2 from the codebase, and so also (I hope) the last remaining reliance on the platform having an integral type with exactly 16 bits. PyUnicode_DecodeUTF16() and PyUnicode_EncodeUTF16() now read and write one byte at a time.
* Sigh. Strengthen the resriction of the previous checkin: tp_new isGuido van Rossum2001-08-091-1/+2
| | | | | inherited unless *both*: (a) the base type is 'object', and (b) the subtype is not a "heap" type.
* Thinking back to the 2.22 revision, I didn't like what I did there oneGuido van Rossum2001-08-091-13/+4
| | | | | | | | | | | | | | | | | bit. For one, this class: class C(object): def __new__(myclass, ...): ... would have no way to call the __new__ method of its base class, and the workaround (to create an intermediate base class whose __new__ you can call) is ugly. So, I've come up with a better solution that restores object.__new__, but still solves the original problem, which is that built-in and extension types shouldn't inherit object.__new__. The solution is simple: only "heap types" inherit tp_new. Simpler, less code, perfect!
* Apply anonymous SF patch #441229.Guido van Rossum2001-08-091-0/+6
| | | | | | | | | | | | Previously, f.read() and f.readlines() checked for errors on their file object and possibly raised an IOError, but f.readline() didn't. This patch makes f.readline() behave like the others. Note that I've added a call to clearerr() since the other calls to ferror() include that too. I have no way to test this code. :-)
* Proper support for binary operators, including true division and floorGuido van Rossum2001-08-081-136/+199
| | | | | | | | | | | | | | | division. The basic binary operators now all correctly call the __rxxx__ variant when they should. In type_new(), I now make the new type a new-style number unless it inherits from an old-style number that has numeric methods. By way of cosmetics, I've changed the signatures of the SLOT<i> macros to take actual function names and operator names as strings, rather than rely on C preprocessor symbol manipulations. This makes the calls slightly more verbose, but greatly helps simple searches through the file: you can now find out where "__radd__" is used or where the function slot_nb_power() is defined and where it is used.
* Removed extraneous semicolons that caused a gazzilion "empty declaration" ↵Jack Jansen2001-08-081-49/+49
| | | | warnings in the MetroWerks compiler.
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-086-24/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | This introduces: - A new operator // that means floor division (the kind of division where 1/2 is 0). - The "future division" statement ("from __future__ import division) which changes the meaning of the / operator to implement "true division" (where 1/2 is 0.5). - New overloadable operators __truediv__ and __floordiv__. - New slots in the PyNumberMethods struct for true and floor division, new abstract APIs for them, new opcodes, and so on. I emphasize that without the future division statement, the semantics of / will remain unchanged until Python 3.0. Not yet implemented are warnings (default off) when / is used with int or long arguments. This has been on display since 7/31 as SF patch #443474. Flames to /dev/null.
* - Rename PyType_InitDict() to PyType_Ready().Guido van Rossum2001-08-072-9/+9
| | | | | | - Add an explicit call to PyType_Ready(&PyList_Type) to pythonrun.c (just for the heck of it, really -- we should either explicitly ready all types, or none).
* Cosmetics:Guido van Rossum2001-08-071-10/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add comment blocks explaining add_operators() and override_slots(). (This file could use some more explaining, but this is all I had breath for today. :) - Renamed the argument 'base' of add_wrappers() to 'wraps' because it's not a base class (which is what the 'base' identifier is used for elsewhere). Small nits: - Fix add_tp_new_wrapper() to avoid overwriting an existing __new__ descriptor in tp_defined. - In add_operators(), check the return value of add_tp_new_wrapper(). Functional change: - Remove the tp_new functionality from PyBaseObject_Type; this means you can no longer instantiate the 'object' type. It's only useful as a base class. - To make up for the above loss, add tp_new to dynamic types. This has to be done in a hackish way (after override_slots() has been called, with an explicit call to add_tp_new_wrapper() at the very end) because otherwise I ran into recursive calls of slot_tp_new(). Sigh.
* Remove spurious "closed" attribute definition from the memberlistGuido van Rossum2001-08-061-1/+0
| | | | table. (reported as an aside in SF #446049).
* A totally new way to do the __new__ wrapper. This should address theGuido van Rossum2001-08-061-34/+45
| | | | problem brought up in SF bug #444229.
* Fix SF #442791 (revisited): No __delitem__ wrapper was defined.Guido van Rossum2001-08-021-0/+35
|
* Fix the test_weakref.py failure. Introduced by resolving "a conflict"Tim Peters2001-08-021-7/+0
| | | | (which didn't actually exist!) incorrectly.
* Merge of descr-branch back into trunk.Tim Peters2001-08-0224-721/+5012
|
* Add _PyUnicode_AsDefaultEncodedString to unicodeobject.h.Jeremy Hylton2001-07-303-24/+0
| | | | | | | And remove all the extern decls in the middle of .c files. Apparently, it was excluded from the header file because it is intended for internal use by the interpreter. It's still intended for internal use and documented as such in the header file.
* 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
generated by cgit v0.12 at 2024-11-18 06:04:58 (GMT)