Correct typos and add bits of discussion. Also add another "chief
virtue".
This commit is contained in:
parent
655faadd09
commit
427ddb1062
40
pep-0234.txt
40
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(): ...
|
||||
|
||||
|
|
Loading…
Reference in New Issue