summaryrefslogtreecommitdiffstats
path: root/Include/abstract.h
Commit message (Collapse)AuthorAgeFilesLines
* Checking in the code for PEP 357.Guido van Rossum2006-03-071-0/+8
| | | | | | This was mostly written by Travis Oliphant. I've inspected it all; Neal Norwitz and MvL have also looked at it (in an earlier incarnation).
* Change some sequnce APIs to use Py_ssize_t.Neal Norwitz2006-03-041-4/+4
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-18/+18
|
* Renamed _length_cue() to __length_hint__(). See:Armin Rigo2006-02-111-5/+10
| | | | http://mail.python.org/pipermail/python-dev/2006-February/060524.html
* Convert iterator __len__() methods to a private API.Raymond Hettinger2005-09-241-0/+15
|
* Make PySequence_Fast_ITEMS public. (Thanks Skip.)Raymond Hettinger2004-03-121-1/+1
|
* Use a new macro, PySequence_Fast_ITEMS to factor out code common toRaymond Hettinger2004-03-121-0/+6
| | | | | three recent optimizations. Aside from reducing code volume, it increases readability.
* Fix a bunch of typos in documentation, docstrings and comments.Walter Dörwald2003-10-201-1/+1
| | | | (From SF patch #810751)
* Fix broken API descriptions in comments.Fred Drake2003-05-121-8/+7
|
* Fix spelling and grammar.Raymond Hettinger2003-02-281-5/+5
|
* James Henstridge pointed out a misleading comment.Michael W. Hudson2002-11-251-10/+6
|
* Excise DL_EXPORT from Include.Mark Hammond2002-08-121-86/+86
| | | | Thanks to Skip Montanaro and Kalle Svensson for the patches.
* Patch #552433: Special-case tuples. Avoid sub-type checking for lists.Martin v. Löwis2002-05-081-0/+6
| | | | | Avoid checks for negative indices and duplicate checks for support of the sequence protocol.
* Implement PyObject_DelItemString. Fixes #498915.Martin v. Löwis2002-01-051-0/+8
|
* Fix SF bug [ #476852 ] Some bad macros in abstract.hJeremy Hylton2001-11-281-2/+2
| | | | Change macros as requested by Guido
* Add PyObject_CheckReadBuffer(), which returns true if its argumentJeremy Hylton2001-11-091-0/+9
| | | | | | supports the single-segment readable buffer interface. Add documentation for this and other PyObject_XXXBuffer() calls.
* PyObject_CallFunctionObArgs() ---> PyObject_CallFunctionObjArgs()Fred Drake2001-10-281-4/+4
| | | | PyObject_CallMethodObArgs() ---> PyObject_CallMethodObjArgs()
* Added two new functions to conveniently call functions/methods from C.Fred Drake2001-10-261-5/+23
| | | | | | | 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-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Generalize operator.indexOf (PySequence_Index) to work with anyTim Peters2001-09-081-8/+18
| | | | | | | | | | 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.
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-081-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+11
|
* Reimplement PySequence_Contains() and instance_contains(), so they workTim Peters2001-05-051-1/+11
| | | | | | | | | 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 tuple() to work nicely with iterators.Tim Peters2001-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | 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-3/+2
| | | | internals) so clients can be a lot dumber (wrt their knowledge).
* Mondo changes to the iterator stuff, without changing how Python codeGuido van Rossum2001-04-231-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | | | | | | | | | | | | | | | | | 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/+7
| | | | | APIs, PyObject_IsInstance() and PyObject_IsSubclass() -- both returning an int, or -1 for errors.
* This patch adds a new builtin unistr() which behaves like str()Marc-André Lemburg2001-01-171-0/+12
| | | | | | | | | | except that it always returns Unicode objects. A new C API PyObject_Unicode() is also provided. This closes patch #101664. Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.
* The real suport for augmented assignment: new opcodes, new PyNumber andThomas Wouters2000-08-241-0/+122
| | | | PySequence methods and functions, new tokens.
* 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.
* Restore PyXXX_Length() APIs for binary compatibility.Marc-André Lemburg2000-07-171-6/+18
| | | | | | New code will see the macros and therefore use the PyXXX_Size() APIs instead. By Thomas Wouters.
* Spelling fixes supplied by Rob W. W. Hooft. All these are fixes in eitherThomas Wouters2000-07-161-1/+1
| | | | | | | | | | comments, docstrings or error messages. I fixed two minor things in test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't"). There is a minor style issue involved: Guido seems to have preferred English grammar (behaviour, honour) in a couple places. This patch changes that to American, which is the more prominent style in the source. I prefer English myself, so if English is preferred, I'd be happy to supply a patch myself ;)
* fix PyXXX_Length macros as suggested by FredJeremy Hylton2000-07-131-3/+3
|
* change abstract size functions PySequence_Size &c.Jeremy Hylton2000-07-121-6/+12
| | | | add macros for backwards compatibility with C source
* ANSI-fication and Py_PROTO extermination.Fred Drake2000-07-091-59/+61
|
* 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-1/+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 Lemburg: added declarations for PyObject_AsCharBuffer,Guido van Rossum2000-03-101-0/+46
| | | | PyObject_AsReadBuffer, PyObject_AsWriteBuffer.
* Add DLL level b/w compat for PySequence_In and PyEval_CallObjectGuido van Rossum1999-03-171-0/+6
|
* Add DL_IMPORT(returntype) for all officially exported functions.Guido van Rossum1998-12-041-51/+51
|
* Move an indented #define to column 1.Guido van Rossum1998-08-231-1/+1
|
* Renamed PySequence_In() to PySequence_Contains().Guido van Rossum1998-05-221-1/+2
|
* Add PyObject_Not().Guido van Rossum1998-04-091-0/+12
|
* A few comment alignment and clarifications.Guido van Rossum1997-03-041-3/+5
|
* Fix the comments for bitwise and/or.Guido van Rossum1997-02-141-6/+6
|
* Added missing for PySequence_List.Guido van Rossum1996-12-051-0/+5
|
* New permission notice, includes CNRI.Guido van Rossum1996-10-251-13/+20
|
* PyMapping_DelItem[String] are actually macros.Guido van Rossum1996-09-061-2/+6
|
generated by cgit v0.12 at 2024-11-21 11:56:32 (GMT)