Added some more discussion.
This commit is contained in:
parent
bc657d06b6
commit
8026ee6829
14
pep-0234.txt
14
pep-0234.txt
|
@ -108,7 +108,10 @@ C API Specification
|
|||
interpreter APIs use the __xxx__ naming scheme. Otherwise, people
|
||||
will have a hard time differentiating between user-level protocols
|
||||
and interpreter-level ones. AFAIK, .next() would be the first
|
||||
low-level API not using this convention."
|
||||
low-level API not using this convention." My (BDFL's) response:
|
||||
there are other important protocols with a user-level name
|
||||
(e.g. keys()), and I don't see the importance of this particular
|
||||
rule.
|
||||
|
||||
|
||||
Python API Specification
|
||||
|
@ -147,7 +150,7 @@ Python API Specification
|
|||
above. A class that wants to be an iterator also ought to
|
||||
implement __iter__() returning itself.
|
||||
|
||||
There is some controversy here:
|
||||
Discussion:
|
||||
|
||||
- The name iter() is an abbreviation. Alternatives proposed
|
||||
include iterate(), harp(), traverse(), narrate().
|
||||
|
@ -157,6 +160,13 @@ Python API Specification
|
|||
with an sentinel value) is somewhat ugly. I haven't seen a
|
||||
better name for the second operation though.
|
||||
|
||||
- It was originally proposed that rather than having a next()
|
||||
method, an iterator object should simply be callable. This was
|
||||
rejected in favor of an explicit next() method. The reason is
|
||||
clarity: if you don't know the code very well, "x = s()" does
|
||||
not give a hint about what it does; but "x = s.next()" is pretty
|
||||
clear.
|
||||
|
||||
|
||||
Dictionary Iterators
|
||||
|
||||
|
|
Loading…
Reference in New Issue