summaryrefslogtreecommitdiffstats
path: root/Lib/test/test_iter.py
Commit message (Collapse)AuthorAgeFilesLines
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-5/+11
| | | | | | | | - 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.
* Teach the UNPACK_SEQUENCE opcode how to tease an iterable object intoTim Peters2001-06-211-0/+53
| | | | | giving up the goods. NEEDS DOC CHANGES
* Generalize zip() to work with iterators.Tim Peters2001-05-061-0/+46
| | | | | | | | NEEDS DOC CHANGES. More AttributeErrors transmuted into TypeErrors, in test_b2.py, and, again, this strikes me as a good thing. This checkin completes the iterator generalization work that obviously needed to be done. Can anyone think of others that should be changed?
* Get rid of silly 5am "del" stmts.Tim Peters2001-05-051-2/+0
|
* Reimplement PySequence_Contains() and instance_contains(), so they workTim Peters2001-05-051-18/+6
| | | | | | | | | 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-0/+35
|
* Make 'x in y' and 'x not in y' (PySequence_Contains) play nice w/ iterators.Tim Peters2001-05-051-0/+55
| | | | | | | | | | | | | 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__.
* Make unicode.join() work nice with iterators. This also required a changeTim Peters2001-05-051-0/+41
| | | | | | | | to string.join(), so that when the latter figures out in midstream that it really needs unicode.join() instead, unicode.join() can actually get all the sequence elements (i.e., there's no guarantee that the sequence passed to string.join() can be iterated over *again* by unicode.join(), so string.join() must not pass on the original sequence object anymore).
* Generalize tuple() to work nicely with iterators.Tim Peters2001-05-051-0/+33
| | | | | | | | | | | | | | | | | | | | | 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.
* Generalize reduce() to work with iterators.Tim Peters2001-05-041-0/+13
| | | | NEEDS DOC CHANGES.
* Purge redundant cut&paste line.Tim Peters2001-05-031-2/+1
|
* Generalize map() to work with iterators.Tim Peters2001-05-031-0/+35
| | | | | | | | | | | NEEDS DOC CHANGES. Possibly contentious: The first time s.next() yields StopIteration (for a given map argument s) is the last time map() *tries* s.next(). That is, if other sequence args are longer, s will never again contribute anything but None values to the result, even if trying s.next() again could yield another result. This is the same behavior map() used to have wrt IndexError, so it's the only way to be wholly backward-compatible. I'm not a fan of letting StopIteration mean "try again later" anyway.
* Remove redundant copy+paste code.Tim Peters2001-05-031-3/+0
|
* Generalize max(seq) and min(seq) to work with iterators.Tim Peters2001-05-031-0/+35
| | | | NEEDS DOC CHANGES.
* Generalize filter(f, seq) to work with iterators. This also generalizesTim Peters2001-05-021-0/+44
| | | | | filter() to no longer insist that len(seq) be defined. NEEDS DOC CHANGES.
* Generalize list(seq) to work with iterators. This also generalizes list()Tim Peters2001-05-011-0/+32
| | | | | | | | | | | | | 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)
* Add test suite for iterators.Guido van Rossum2001-04-211-0/+246
generated by cgit v0.12 at 2024-10-09 18:22:39 (GMT)