Correct typos and add bits of discussion. Also add another "chief

virtue".
This commit is contained in:
Guido van Rossum 2001-05-01 11:42:07 +00:00
parent 655faadd09
commit 427ddb1062
1 changed files with 28 additions and 12 deletions

View File

@ -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(): ...