summaryrefslogtreecommitdiffstats
path: root/Objects/abstract.c
Commit message (Collapse)AuthorAgeFilesLines
* Squash a few calls to the hideously expensive PyObject_CallObject(o,a)Guido van Rossum2002-08-161-2/+2
| | | | | | | -- 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.)
* Patch #554716: Use __va_copy where available.Martin v. Löwis2002-07-281-0/+4
|
* Close SF bug 563740. complex() now finds __complex__() in new style classes.Raymond Hettinger2002-06-061-2/+2
| | | | | Made conversion failure error messages consistent between types. Added related unittests.
* Better isinstance error message.Thomas Heller2002-06-051-1/+2
| | | | | | Closes SF patch # 560250. Bugfix candidate IMO.
* abstract_get_bases(): Clarify exactly what the return values andBarry Warsaw2002-04-231-9/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | states can be for this function, and ensure that only AttributeErrors are masked. Any other exception raised via the equivalent of getattr(cls, '__bases__') should be propagated up. abstract_issubclass(): If abstract_get_bases() returns NULL, we must call PyErr_Occurred() to see if an exception is being propagated, and return -1 or 0 as appropriate. This is the specific fix for a problem whereby if getattr(derived, '__bases__') raised an exception, an "undetected error" would occur (under a debug build). This nasty situation was uncovered when writing a security proxy extension type for the Zope3 project, where the security proxy raised a Forbidden exception on getattr of __bases__. PyObject_IsInstance(), PyObject_IsSubclass(): After both calls to abstract_get_bases(), where we're setting the TypeError if the return value is NULL, we must first check to see if an exception occurred, and /not/ mask an existing exception. Neil Schemenauer should double check that these changes don't break his ExtensionClass examples (there aren't any test cases for those examples and abstract_get_bases() was added by him in response to problems with ExtensionClass). Neil, please add test cases if possible! I belive this is a bug fix candidate for Python 2.2.2.
* SF bug 544647.Guido van Rossum2002-04-161-2/+6
| | | | | | | | | PyNumber_InPlaceMultiply insisted on calling sq_inplace_repeat if it existed, even if nb_inplace_multiply also existed and the arguments weren't right for sq_inplace_repeat. Change this to only use sq_inplace_repeat if nb_inplace_multiply isn't defined. Bugfix candidate.
* Whitespace normalization and fold some long lines.Guido van Rossum2002-04-161-20/+19
|
* Fix leak of NotImplemented in previous checkin to PyNumber_Add().Jeremy Hylton2002-03-081-4/+6
| | | | | If result == Py_NotImplemented, always DECREF it before assigning a new value to result.
* Fix for SF bug 516727: MyInt(2) + "3" -> NotImplementedJeremy Hylton2002-03-081-4/+3
| | | | | | PyNumber_Add() tries the nb_add slot first, then falls back to sq_concat. However, tt didn't check the return value of sq_concat. If sq_concat returns NotImplemented, raise the standard TypeError.
* Revert the last odd change to PyNumber_Long: the problem it was tryingTim Peters2002-03-021-10/+2
| | | | to fix was almost certainly a bug in _PyLong_Copy (which I'll fix next).
* SF patch 514641 (Naofumi Honda) - Negative ob_size of LongObjectsGuido van Rossum2002-03-011-2/+10
| | | | | | | | | | Due to the bizarre definition of _PyLong_Copy(), creating an instance of a subclass of long with a negative value could cause core dumps later on. Unfortunately it looks like the behavior of _PyLong_Copy() is quite intentional, so the fix is more work than feels comfortable. This fix is almost, but not quite, the code that Naofumi Honda added; in addition, I added a test case.
* Implement PyObject_DelItemString. Fixes #498915.Martin v. Löwis2002-01-051-0/+18
|
* PyObject_GetItem(), PyObject_SetItem(), PyObject_DelItem(): Fix a fewGuido van Rossum2001-11-241-5/+10
| | | | | | | confusing error messages. If a new-style class has no sequence or mapping behavior, attempting to use the indexing notation with a non-integer key would complain that the sequence index must be an integer, rather than complaining that the operation is not supported.
* Add PyObject_CheckReadBuffer(), which returns true if its argumentJeremy Hylton2001-11-091-29/+35
| | | | | | supports the single-segment readable buffer interface. Add documentation for this and other PyObject_XXXBuffer() calls.
* PyFunction_Call() did not check the result of PyObject_Repr() for NULL, andFred Drake2001-11-011-2/+2
| | | | | | | should just avoid calling it in the first place to avoid waiting for a repr of a large object like a dict or list. The result of PyObject_Repr() was being leaked as well. Bugfix candidate!
* PyObject_CallFunctionObArgs() ---> PyObject_CallFunctionObjArgs()Fred Drake2001-10-281-5/+5
| | | | PyObject_CallMethodObArgs() ---> PyObject_CallMethodObjArgs()
* PyObject_CallFunction(), PyObject_CallMethod(): Make sure we do not touchFred Drake2001-10-271-18/+11
| | | | | | the va_list until we are sure we have a format string and need to use it; this avoid premature initialization and having to finalize it several different places because of error returns.
* Added two new functions to conveniently call functions/methods from C.Fred Drake2001-10-261-0/+76
| | | | | | | PyObject_CallFunctionObArgs() and PyObject_CallMethodObArgs() have the advantage that no format strings need to be parsed. The CallMethod variant also avoids creating a new string object in order to retrieve a method from an object as well.
* Generalize dictionary() to accept a sequence of 2-sequences. At theTim Peters2001-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | outer level, the iterator protocol is used for memory-efficiency (the outer sequence may be very large if fully materialized); at the inner level, PySequence_Fast() is used for time-efficiency (these should always be sequences of length 2). dictobject.c, new functions PyDict_{Merge,Update}FromSeq2. These are wholly analogous to PyDict_{Merge,Update}, but process a sequence-of-2- sequences argument instead of a mapping object. For now, I left these functions file static, so no corresponding doc changes. It's tempting to change dict.update() to allow a sequence-of-2-seqs argument too. Also changed the name of dictionary's keyword argument from "mapping" to "x". Got a better name? "mapping_or_sequence_of_pairs" isn't attractive, although more so than "mosop" <wink>. abstract.h, abstract.tex: Added new PySequence_Fast_GET_SIZE function, much faster than going thru the all-purpose PySequence_Size. libfuncs.tex: - Document dictionary(). - Fiddle tuple() and list() to admit that their argument is optional. - The long-winded repetitions of "a sequence, a container that supports iteration, or an iterator object" is getting to be a PITA. Many months ago I suggested factoring this out into "iterable object", where the definition of that could include being explicit about generators too (as is, I'm not sure a reader outside of PythonLabs could guess that "an iterator object" includes a generator call). - Please check my curly braces -- I'm going blind <0.9 wink>. abstract.c, PySequence_Tuple(): When PyObject_GetIter() fails, leave its error msg alone now (the msg it produces has improved since PySequence_Tuple was generalized to accept iterable objects, and PySequence_Tuple was also stomping on the msg in cases it shouldn't have even before PyObject_GetIter grew a better msg).
* Make the error message for unsupported operand types cleaner, inGuido van Rossum2001-10-221-7/+27
| | | | | | | | | | | | response to a message by Laura Creighton on c.l.py. E.g. >>> 0+'' TypeError: unsupported operand types for +: 'int' and 'str' (previously this did not mention the operand types) >>> ''+0 TypeError: cannot concatenate 'str' and 'int' objects
* Fix error checking done by abstract_issubclass and abstract_isinstance.Neil Schemenauer2001-10-181-44/+61
| | | | | | isinstance() now allows any object as the first argument and a class, a type or something with a __bases__ tuple attribute for the second argument. This closes SF patch #464992.
* Implement isinstance(x, (A, B, ...)). Note that we only allow tuples,Guido van Rossum2001-10-071-1/+16
| | | | | not other sequences (then we'd have to except strings, and we'd still be susceptible to recursive attacks).
* binary_op1(), ternary_op(): rearrange the code so that slotw is testedGuido van Rossum2001-10-011-14/+14
| | | | | (to see whether __rop__ should go before __op__) only when slotv is set. This saves a test+branch when only slotw is set.
* SF bug [#466173] unpack TypeError unclearTim Peters2001-09-301-1/+1
| | | | | | Replaced 3 instances of "iter() of non-sequence" with "iteration over non-sequence". Restored "unpack non-sequence" for stuff like "a, b = 1".
* The changes to ternary_op could cause a core dump. Fix this, andGuido van Rossum2001-09-291-55/+44
| | | | rewrite the code a bit to avoid calling the same slot more than once.
* It's a fact: for binary operators, *under certain circumstances*,Guido van Rossum2001-09-281-28/+48
| | | | | | | | | | | | | __rop__ now takes precendence over __op__. Those circumstances are: - Both arguments are new-style classes - Both arguments are new-style numbers - Their implementation slots for tp_op differ - Their types differ - The right argument's type is a subtype of the left argument's type Also did this for the ternary operator (pow) -- only the binary case is dealt with properly though, since __rpow__ is not supported anyway.
* PyObject_CallObject(): this may as well call PyEval_CallObject()Guido van Rossum2001-09-141-16/+1
| | | | | | | | | | | | | | | directly, as the only thing done here (replace NULL args with an empty tuple) is also done there. XXX Maybe we should take one step further and equate the two at the macro level? That's harder though because PyEval_Call* is declared in a header that's not included standard. But it is silly that PyObject_CallObject calls PyEval_CallObject which calls back to PyObject_Call. Maybe PyEval_CallObject should be moved into this file instead? All I know is that there are too many call APIs! The differences between PyObject_Call and PyEval_CallObjectWithKeywords is that the latter allows args to be NULL, and does explicit type checks for args and kwds.
* Fix tortured comment -- I must be on drugs today.Tim Peters2001-09-101-2/+2
|
* More on SF bug [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-101-1/+5
| | | | | | | | tuple(i) repaired to return a true tuple when i is an instance of a tuple subclass. Added PyTuple_CheckExact macro. PySequence_Tuple(): if a tuple-like object isn't exactly a tuple, it's not safe to return the object as-is -- make a new tuple of it instead.
* More for SF bug [#460020] bug or feature: unicode() and subclassesTim Peters2001-09-101-1/+5
| | | | | Repair float constructor to return a true float when passed a subclass instance. New PyFloat_CheckExact macro.
* SF bug #460020: bug or feature: unicode() and subclasses.Tim Peters2001-09-101-2/+9
| | | | | | | | | | | Given an immutable type M, and an instance I of a subclass of M, the constructor call M(I) was just returning I as-is; but it should return a new instance of M. This fixes it for M in {int, long}. Strings, floats and tuples remain to be done. Added new macros PyInt_CheckExact and PyLong_CheckExact, to more easily distinguish between "is" and "is a" (i.e., only an int passes PyInt_CheckExact, while any sublass of int passes PyInt_Check). Added private API function _PyLong_Copy.
* Generalize operator.indexOf (PySequence_Index) to work with anyTim Peters2001-09-081-72/+62
| | | | | | | | | | iterable object. I'm not sure how that got overlooked before! Got rid of the internal _PySequence_IterContains, introduced a new internal _PySequence_IterSearch, and rewrote all the iteration-based "count of", "index of", and "is the object in it or not?" routines to just call the new function. I suppose it's slower this way, but the code duplication was getting depressing.
* PySequence_Check(), PyMapping_Check(): only return true if theGuido van Rossum2001-09-071-2/+4
| | | | | | | | | | | | | | | corresponding "getitem" operation (sq_item or mp_subscript) is implemented. I realize that "sequence-ness" and "mapping-ness" are poorly defined (and the tests may still be wrong for user-defined instances, which always have both slots filled), but I believe that a sequence that doesn't support its getitem operation should not be considered a sequence. All other operations are optional though. For example, the ZODB BTree tests crashed because PySequence_Check() returned true for a dictionary! (In 2.2, the dictionary type has a tp_as_sequence pointer, but the only field filled is sq_contains, so you can write "if key in dict".) With this fix, all standalone ZODB tests succeed.
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-0/+8
| | | | | | | | - Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled - check for Py_USING_UNICODE in all places that use Unicode functions - disables unicode literals, and the builtin functions - add the types.StringTypes list - remove Unicode literals from most tests.
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-081-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-1/+19
|
* Cruft cleanup: Removed the unused last_is_sticky argument from the internalTim Peters2001-05-281-2/+2
| | | | _PyTuple_Resize().
* Reimplement PySequence_Contains() and instance_contains(), so they workTim Peters2001-05-051-21/+20
| | | | | | | | | safely together and don't duplicate logic (the common logic was factored out into new private API function _PySequence_IterContains()). Visible change: some_complex_number in some_instance no longer blows up if some_instance has __getitem__ but neither __contains__ nor __iter__. test_iter changed to ensure that remains true.
* Generalize PySequence_Count() (operator.countOf) to work with iterators.Tim Peters2001-05-051-13/+31
|
* Make 'x in y' and 'x not in y' (PySequence_Contains) play nice w/ iterators.Tim Peters2001-05-051-29/+34
| | | | | | | | | | | | | NEEDS DOC CHANGES A few more AttributeErrors turned into TypeErrors, but in test_contains this time. The full story for instance objects is pretty much unexplainable, because instance_contains() tries its own flavor of iteration-based containment testing first, and PySequence_Contains doesn't get a chance at it unless instance_contains() blows up. A consequence is that some_complex_number in some_instance dies with a TypeError unless some_instance.__class__ defines __iter__ but does not define __getitem__.
* Fix a tiny and unlikely memory leak. Was there before too, and actuallyTim Peters2001-05-051-1/+3
| | | | several of these turned up and got fixed during the iteration crusade.
* Generalize tuple() to work nicely with iterators.Tim Peters2001-05-051-40/+47
| | | | | | | | | | | | | | | | | | | | | NEEDS DOC CHANGES. This one surprised me! While I expected tuple() to be a no-brainer, turns out it's actually dripping with consequences: 1. It will *allow* the popular PySequence_Fast() to work with any iterable object (code for that not yet checked in, but should be trivial). 2. It caused two std tests to fail. This because some places used PyTuple_Sequence() (the C spelling of tuple()) as an indirect way to test whether something *is* a sequence. But tuple() code only looked for the existence of sq->item to determine that, and e.g. an instance passed that test whether or not it supported the other operations tuple() needed (e.g., __len__). So some things the tests *expected* to fail with an AttributeError now fail with a TypeError instead. This looks like an improvement to me; e.g., test_coercion used to produce 559 TypeErrors and 2 AttributeErrors, and now they're all TypeErrors. The error details are more informative too, because the places calling this were *looking* for TypeErrors in order to replace the generic tuple() "not a sequence" msg with their own more specific text, and AttributeErrors snuck by that.
* Make PyIter_Next() a little smarter (wrt its knowledge of iteratorTim Peters2001-05-051-11/+16
| | | | internals) so clients can be a lot dumber (wrt their knowledge).
* Plug a memory leak in list(), when appending to the result list.Tim Peters2001-05-021-5/+9
|
* Generalize list(seq) to work with iterators. This also generalizes list()Tim Peters2001-05-011-31/+57
| | | | | | | | | | | | | to no longer insist that len(seq) be defined. NEEDS DOC CHANGES. This is meant to be a model for how other functions of this ilk (max, filter, etc) can be generalized similarly. Feel encouraged to grab your favorite and convert it! Note some cute consequences: list(file) == file.readlines() == list(file.xreadlines()) list(dict) == dict.keys() list(dict.iteritems()) = dict.items() list(xrange(i, j, k)) == range(i, j, k)
* Mondo changes to the iterator stuff, without changing how Python codeGuido van Rossum2001-04-231-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
* Iterators phase 1. This comprises:Guido van Rossum2001-04-201-0/+17
| | | | | | | | | | | | | | | | | | | | | | new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
* Move the code implementing isinstance() and issubclass() to new CGuido van Rossum2001-03-211-0/+112
| | | | | APIs, PyObject_IsInstance() and PyObject_IsSubclass() -- both returning an int, or -1 for errors.
* Rich comparisons fall-out:Guido van Rossum2001-01-171-4/+4
| | | | | | - Renamed Py_TPFLAGS_NEWSTYLENUMBER to Py_TPFLAGS_CHECKTYPES. - Use PyObject_RichCompareBool() in PySequence_Contains().
* Massive changes as per PEP 208. Read it for details.Neil Schemenauer2001-01-041-728/+318
|
generated by cgit v0.12 at 2024-09-25 21:16:20 (GMT)