[Python-checkins] CVS: python/nondist/peps pep-0234.txt,1.15,1.16

2001年10月25日 13:14:03 -0700

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv7249
Modified Files:
	pep-0234.txt 
Log Message:
Moved all the Open Issues to Resolved Issues, with a brief explanation
of how they were resolved. Mark this PEP as Final.
Index: pep-0234.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0234.txt,v
retrieving revision 1.15
retrieving revision 1.16
diff -C2 -d -r1.15 -r1.16
*** pep-0234.txt	2001年05月05日 00:14:56	1.15
--- pep-0234.txt	2001年10月25日 20:14:01	1.16
***************
*** 3,7 ****
 Version: $Revision$
 Author: ping@lfw.org (Ka-Ping Yee), guido@python.org (Guido van Rossum)
! Status: Draft
 Type: Standards Track
 Python-Version: 2.1
--- 3,7 ----
 Version: $Revision$
 Author: ping@lfw.org (Ka-Ping Yee), guido@python.org (Guido van Rossum)
! Status: Final
 Type: Standards Track
 Python-Version: 2.1
***************
*** 255,262 ****

! Open Issues

! The following questions are still open.

 - The name iter() is an abbreviation. Alternatives proposed
 include iterate(), traverse(), but these appear too long.
--- 255,323 ----

! Resolved Issues

! The following topics have been decided by consensus or BDFL
! pronouncement.
! 
! - Two alternative spellings for next() have been proposed but
! rejected: __next__(), because it corresponds to a type object
! slot (tp_iternext); and __call__(), because this is the only
! operation.
! 
! Arguments against __next__(): while many iterators are used in
! for loops, it is expected that user code will also call next()
! directly, so having to write __next__() is ugly; also, a
! possible extension of the protocol would be to allow for prev(),
! current() and reset() operations; surely we don't want to use
! __prev__(), __current__(), __reset__().
! 
! Arguments against __call__() (the original proposal): taken out
! of context, x() is not very readable, while x.next() is clear;
! there's a danger that every special-purpose object wants to use
! __call__() for its most common operation, causing more confusion
! than clarity.
! 
! - Some folks have requested the ability to restart an iterator.
! This should be dealt with by calling iter() on a sequence
! repeatedly, not by the iterator protocol itself.
! 
! - It has been questioned whether an exception to signal the end of
! the iteration isn't too expensive. Several alternatives for the
! StopIteration exception have been proposed: a special value End
! to signal the end, a function end() to test whether the iterator
! is finished, even reusing the IndexError exception.
! 
! - A special value has the problem that if a sequence ever
! contains that special value, a loop over that sequence will
! end prematurely without any warning. If the experience with
! null-terminated C strings hasn't taught us the problems this
! can cause, imagine the trouble a Python introspection tool
! would have iterating over a list of all built-in names,
! assuming that the special End value was a built-in name!

+ - Calling an end() function would require two calls per
+ iteration. Two calls is much more expensive than one call
+ plus a test for an exception. Especially the time-critical
+ for loop can test very cheaply for an exception.
+ 
+ - Reusing IndexError can cause confusion because it can be a
+ genuine error, which would be masked by ending the loop
+ prematurely.
+ 
+ - Some have asked for a standard iterator type. Presumably all
+ iterators would have to be derived from this type. But this is
+ not the Python way: dictionaries are mappings because they
+ support __getitem__() and a handful other operations, not
+ because they are derived from an abstract mapping type.
+ 
+ - Regarding "if key in dict": there is no doubt that the
+ dict.has_keys(x) interpretation of "x in dict" is by far the
+ most useful interpretation, probably the only useful one. There
+ has been resistance against this because "x in list" checks
+ whether x is present among the values, while the proposal makes
+ "x in dict" check whether x is present among the keys. Given
+ that the symmetry between lists and dictionaries is very weak,
+ this argument does not have much weight.
+ 
 - The name iter() is an abbreviation. Alternatives proposed
 include iterate(), traverse(), but these appear too long.
***************
*** 264,267 ****
--- 325,330 ----
 e.g. repr(), str(), len().

+ Resolution: iter() it is.
+ 
 - Using the same name for two different operations (getting an
 iterator from an object and making an iterator for a function
***************
*** 270,273 ****
--- 333,339 ----
 return an iterator, it's easy to remember.

+ Resolution: the builtin iter() takes an optional argument, which
+ is the sentinel to look for.
+ 
 - Once a particular iterator object has raised StopIteration, will
 it also raise StopIteration on all subsequent next() calls?
***************
*** 277,280 ****
--- 343,349 ----
 iterator implementations (e.g. function-wrapping iterators).

+ Resolution: once StopIteration is raised, calling it.next()
+ continues to raise StopIteration.
+ 
 - It has been proposed that a file object should be its own
 iterator, with a next() method returning the next line. This
***************
*** 284,287 ****
--- 353,358 ----
 StopIteration" feature proposed in the previous bullet.

+ Resolution: this has been implemented.
+ 
 - Some folks have requested extensions of the iterator protocol,
 e.g. prev() to get the previous item, current() to get the
***************
*** 298,301 ****
--- 369,374 ----
 operations when the are implementable.

+ Resolution: rejected.
+ 
 - There is still discussion about whether

***************
*** 334,403 ****

 and found that the latter is only about 7% faster.
- 
- 
- Resolved Issues
- 
- The following topics have been decided by consensus or BDFL
- pronouncement.
- 
- - Two alternative spellings for next() have been proposed but
- rejected: __next__(), because it corresponds to a type object
- slot (tp_iternext); and __call__(), because this is the only
- operation.
- 
- Arguments against __next__(): while many iterators are used in
- for loops, it is expected that user code will also call next()
- directly, so having to write __next__() is ugly; also, a
- possible extension of the protocol would be to allow for prev(),
- current() and reset() operations; surely we don't want to use
- __prev__(), __current__(), __reset__().
- 
- Arguments against __call__() (the original proposal): taken out
- of context, x() is not very readable, while x.next() is clear;
- there's a danger that every special-purpose object wants to use
- __call__() for its most common operation, causing more confusion
- than clarity.
- 
- - Some folks have requested the ability to restart an iterator.
- This should be dealt with by calling iter() on a sequence
- repeatedly, not by the iterator protocol itself.
- 
- - It has been questioned whether an exception to signal the end of
- the iteration isn't too expensive. Several alternatives for the
- StopIteration exception have been proposed: a special value End
- to signal the end, a function end() to test whether the iterator
- is finished, even reusing the IndexError exception.
- 
- - A special value has the problem that if a sequence ever
- contains that special value, a loop over that sequence will
- end prematurely without any warning. If the experience with
- null-terminated C strings hasn't taught us the problems this
- can cause, imagine the trouble a Python introspection tool
- would have iterating over a list of all built-in names,
- assuming that the special End value was a built-in name!
- 
- - Calling an end() function would require two calls per
- iteration. Two calls is much more expensive than one call
- plus a test for an exception. Especially the time-critical
- for loop can test very cheaply for an exception.
- 
- - Reusing IndexError can cause confusion because it can be a
- genuine error, which would be masked by ending the loop
- prematurely.

! - Some have asked for a standard iterator type. Presumably all
! iterators would have to be derived from this type. But this is
! not the Python way: dictionaries are mappings because they
! support __getitem__() and a handful other operations, not
! because they are derived from an abstract mapping type.
! 
! - Regarding "if key in dict": there is no doubt that the
! dict.has_keys(x) interpretation of "x in dict" is by far the
! most useful interpretation, probably the only useful one. There
! has been resistance against this because "x in list" checks
! whether x is present among the values, while the proposal makes
! "x in dict" check whether x is present among the keys. Given
! that the symmetry between lists and dictionaries is very weak,
! this argument does not have much weight.

--- 407,415 ----

 and found that the latter is only about 7% faster.

! Resolution: By BDFL pronouncement, "for x in dict" iterates over
! the keys, and dictionaries have iteritems(), iterkeys(), and
! itervalues() to return the different flavors of dictionary
! iterators.