From 427ddb1062e5e35811cfd8f94835777d169ea619 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Tue, 1 May 2001 11:42:07 +0000 Subject: [PATCH] Correct typos and add bits of discussion. Also add another "chief virtue". --- pep-0234.txt | 40 ++++++++++++++++++++++++++++------------ 1 file changed, 28 insertions(+), 12 deletions(-) diff --git a/pep-0234.txt b/pep-0234.txt index 42a96a566..403209452 100644 --- a/pep-0234.txt +++ b/pep-0234.txt @@ -19,7 +19,7 @@ Abstract In addition, specific iterators over the keys of a dictionary and over the lines of a file are proposed, and a proposal is made to - allow spelling dict.kas_key(key) as "key in dict". + allow spelling dict.has_key(key) as "key in dict". Note: this is an almost complete rewrite of this PEP by the second author, describing the actual implementation checked into the @@ -116,14 +116,14 @@ Python API Specification return value does not equal the sentinel, it is returned as the next value from the iterator. If the callable raises an exception, this is propagated normally; in particular, the - function is allowed to raise StopError as an alternative way to - end the iteration. (This functionality is available from the C - API as PyCallIter_New(callable, sentinel).) + function is allowed to raise StopIteration as an alternative way + to end the iteration. (This functionality is available from the + C API as PyCallIter_New(callable, sentinel).) Iterator objects returned by either form of iter() have a next() method. This method either returns the next value in the - iteration, or raises StopError (or a derived exception class) to - signal the end of the iteration. Any other exception should be + iteration, or raises StopIteration (or a derived exception class) + to signal the end of the iteration. Any other exception should be considered to signify an error and should be propagated normally, not taken to mean the end of the iteration. @@ -212,11 +212,11 @@ Rationale If all the parts of the proposal are included, this addresses many concerns in a consistent and flexible fashion. Among its chief - virtues are the following three -- no, four -- no, five -- points: + virtues are the following four -- no, five -- no, six -- points: 1. It provides an extensible iterator interface. - 1. It allows performance enhancements to list iteration. + 2. It allows performance enhancements to list iteration. 3. It allows big performance enhancements to dictionary iteration. @@ -228,18 +228,24 @@ Rationale mappings, even mappings that only implement a subset of {__getitem__, keys, values, items}. + 6. It makes code iterating over non-sequence collections more + concise and readable. + Open Issues The following questions are still open. - The name iter() is an abbreviation. Alternatives proposed - include iterate(), harp(), traverse(), narrate(). + include iterate(), traverse(), but these appear too long. + Python has a history of using abbrs for common builtins, + e.g. repr(), str(), len(). - Using the same name for two different operations (getting an iterator from an object and making an iterator for a function with an sentinel value) is somewhat ugly. I haven't seen a - better name for the second operation though. + better name for the second operation though, and since they both + return an iterator, it's easy to remember. - Once a particular iterator object has raised StopIteration, will it also raise StopIteration on all subsequent next() calls? @@ -286,8 +292,18 @@ Open Issues this is true, I (Guido) find the correspondence between "for x in dict" and "if x in dict" too compelling to break, and there's not much overhead in having to write dict[x] to explicitly get the - value. We could also add methods to dictionaries that return - different kinds of iterators, e.g. + value. I've also timed the difference between + + for key in dict: dict[key] + + and + + for key, value in dict[key]: pass + + and found that these run at about the same speed. + + We could also add methods to dictionaries that return different + kinds of iterators, e.g. for key, value in dict.iteritems(): ...