BDFL pronouncement on next() vs. __next__() vs. __call__().

Add mailing list pointers.

Add discussion on "once-stopped-always-stopped".
This commit is contained in:
Guido van Rossum 2001-04-27 15:26:54 +00:00
parent 811c26b6de
commit 619a17e425
1 changed files with 22 additions and 2 deletions

View File

@ -111,7 +111,7 @@ C API Specification
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.
rule. BDFL pronouncement: this topic is closed. next() it is.
Python API Specification
@ -160,12 +160,20 @@ Python API Specification
with an sentinel value) is somewhat ugly. I haven't seen a
better name for the second operation though.
- There's a bit of undefined behavior for iterators: once a
particular iterator object has raised StopIteration, will it
also raise StopIteration on all subsequent next() calls? Some
say that it would be useful to require this, others say that it
is useful to leave this open to individual iterators. Note that
this may require an additional state bit for some iterator
implementations (e.g. function-wrapping iterators).
- 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.
clear. BDFL pronouncement: this topic is closed. next() it is.
Dictionary Iterators
@ -297,6 +305,18 @@ Rationale
{__getitem__, keys, values, items}.
Mailing Lists
The iterator protocol has been discussed extensively in a mailing
list on SourceForge:
http://lists.sourceforge.net/lists/listinfo/python-iterators
Initially, some of the discussion was carried out at Yahoo;
archives are still accessible:
http://groups.yahoo.com/group/python-iter
Copyright
This document is in the public domain.