summaryrefslogtreecommitdiff
path: root/Objects/abstract.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Fix for SF bug #115987: PyInstance_HalfBinOp does not initialize theThomas Wouters2000-10-051-11/+11
| | | | | | result-object-pointer that is passed in, when an exception occurs during coercion. The pointer has to be explicitly initialized in the caller to avoid putting trash on the Python stack.
* Cosmetic cleanup by Vladimir.Thomas Wouters2000-09-021-43/+49
|
* Rewritten some pieces of PyNumber_InPlaceAdd() for clarity.Guido van Rossum2000-09-011-15/+20
|
* Fix grouping, again. This time properly :-) Sorry, guys.Thomas Wouters2000-09-011-3/+3
|
* Add parens suggested by gcc -Wall.Guido van Rossum2000-09-011-2/+3
|
* Fix grouping: this is how I intended it, misguided as I was in booleanThomas Wouters2000-08-311-2/+2
| | | | operator associativity.
* Removed compiler warning about wanting explicit grouping around &&Fred Drake2000-08-311-4/+6
| | | | | expression next to a || expression; this is a readability-inspired warning from GCC.
* Support for the in-place operations introduced by augmented assignment. OnlyThomas Wouters2000-08-241-0/+514
| | | | | the list object supports this currently, but other candidates are gladly accepted (like arraymodule and such.)
* Addendum to previous change: now that 'f' is not unconditionallyThomas Wouters2000-08-231-11/+11
| | | | initialized in the 'if (..)', do so manually.
* Add extra check on whether 'tp_as_number' is still non-NULL after coercion,Thomas Wouters2000-08-231-24/+28
| | | | | in the PyNumber_* functions. Also, remove unnecessary tests from PyNumber_Multiply: after BINOP(), neither argument can be an instance.
* Apply SF patch #101029: call __getitem__ with a proper slice object if thereThomas Wouters2000-08-171-0/+37
| | | | | | | | is no __getslice__ available. Also does the same for C extension types. Includes rudimentary documentation (it could use a cross reference to the section on slice objects, I couldn't figure out how to do that) and a test suite for all Python __hooks__ I could think of, including the new behaviour.
* Remobe beopen/cnri/cwi copyrights, according to CNRI instructions.Guido van Rossum2000-08-031-10/+0
| | | | | | This doesn't change the copyright status for these files -- just the markings! Doing it on the main branch for these three files for which the HEAD revision was pushed back into 1.6.
* ANSIfication: remove very-old-varargs code, fix function declarations soThomas Wouters2000-07-221-34/+0
| | | | they include prototypes.
* Restore PyXXX_Length() APIs for binary compatibility.Marc-André Lemburg2000-07-171-0/+24
| | | | | | New code will see the macros and therefore use the PyXXX_Size() APIs instead. By Thomas Wouters.
* change abstract size functions PySequence_Size &c.Jeremy Hylton2000-07-121-8/+8
| | | | add macros for backwards compatibility with C source
* type_error(): Added "const" to signature to eliminate warning with -Wall.Fred Drake2000-07-091-1/+1
|
* ANSI-fication of the sources.Fred Drake2000-07-091-140/+55
|
* Nuke all remaining occurrences of Py_PROTO and Py_FPROTO.Tim Peters2000-07-091-13/+13
|
* Change copyright notice - 2nd try.Guido van Rossum2000-06-301-6/+0
|
* Change copyright notice.Guido van Rossum2000-06-301-22/+7
|
* Patch from /F:Andrew M. Kuchling2000-06-181-0/+20
| | | | | this patch introduces PySequence_Fast and PySequence_Fast_GET_ITEM, and modifies the list.extend method to accept any kind of sequence.
* Marc-Andre's third try at this bulk patch seems to work (except thatGuido van Rossum2000-04-051-42/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | his copy of test_contains.py seems to be broken -- the lines he deleted were already absent). Checkin messages: New Unicode support for int(), float(), complex() and long(). - new APIs PyInt_FromUnicode() and PyLong_FromUnicode() - added support for Unicode to PyFloat_FromString() - new encoding API PyUnicode_EncodeDecimal() which converts Unicode to a decimal char* string (used in the above new APIs) - shortcuts for calls like int(<int object>) and float(<float obj>) - tests for all of the above Unicode compares and contains checks: - comparing Unicode and non-string types now works; TypeErrors are masked, all other errors such as ValueError during Unicode coercion are passed through (note that PyUnicode_Compare does not implement the masking -- PyObject_Compare does this) - contains now works for non-string types too; TypeErrors are masked and 0 returned; all other errors are passed through Better testing support for the standard codecs. Misc minor enhancements, such as an alias dbcs for the mbcs codec. Changes: - PyLong_FromString() now applies the same error checks as does PyInt_FromString(): trailing garbage is reported as error and not longer silently ignored. The only characters which may be trailing the digits are 'L' and 'l' -- these are still silently ignored. - string.ato?() now directly interface to int(), long() and float(). The error strings are now a little different, but the type still remains the same. These functions are now ready to get declared obsolete ;-) - PyNumber_Int() now also does a check for embedded NULL chars in the input string; PyNumber_Long() already did this (and still does) Followed by: Looks like I've gone a step too far there... (and test_contains.py seem to have a bug too). I've changed back to reporting all errors in PyUnicode_Contains() and added a few more test cases to test_contains.py (plus corrected the join() NameError).
* Many changes for Unicode, by Marc-Andre Lemburg.Guido van Rossum2000-03-101-14/+134
|
* Patch by Moshe Zadka: remove the string special case inGuido van Rossum2000-03-071-18/+0
| | | | | PySequence_Contains() now that string objects have this code in their tp_contains.
* Patch by Mozhe Zadka, for __contains__ (overloading 'in'). ThisGuido van Rossum2000-02-281-1/+8
| | | | | patches PySequence_Contains() to check for a valid sq_contains field. More to follow.
* Allow using long integers as arguments to PyObject_GetItem(), _SetItem(),Andrew M. Kuchling2000-02-231-1/+19
| | | | | | and _DelItem(). In sequence multiplication by a long, only call PyErr_Occurred() when the value returned is -1.
View Lorry Controller Status