[Python-checkins] python/nondist/peps pep-0322.txt,1.4,1.5

Sat Sep 27 22:43:39 EDT 2003

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv11863
Modified Files:
	pep-0322.txt 
Log Message:
* Rename the proposed method to "iterreverse"
* Make recommendations on the open issues.
* Minor wording changes.
Index: pep-0322.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0322.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** pep-0322.txt	26 Sep 2003 16:09:54 -0000	1.4
--- pep-0322.txt	28 Sep 2003 02:43:37 -0000	1.5
***************
*** 37,41 ****
 print value

! Extending slicing is a third approach that minimizes the code overhead
 but does nothing for memory efficiency, beauty, or clarity.

--- 37,41 ----
 print value

! Extended slicing is a third approach that minimizes the code overhead
 but does nothing for memory efficiency, beauty, or clarity.

***************
*** 47,65 ****
 ========

! Add a method called *ireverse()* to sequence objects that can
 benefit from it. The above examples then simplify to::

! for i in xrange(n).ireverse():
 print seqn[i]

 ::

! for elem in seqn.ireverse():
 print elem

! The new protocol would be applied to lists, strings, xrange objects,
! and possibly other sequence objects as well (depending on use cases
! and implementation issues). It would not apply to unordered
! collections like dicts and sets.

 No language syntax changes are needed.
--- 47,64 ----
 ========

! Add a method called *iterreverse()* to sequence objects that can
 benefit from it. The above examples then simplify to::

! for i in xrange(n).iterreverse():
 print seqn[i]

 ::

! for elem in seqn.iterreverse():
 print elem

! The new protocol would be applied to lists, tuples, strings, and
! xrange objects. It would not apply to unordered collections like
! dicts and sets.

 No language syntax changes are needed.
***************
*** 74,89 ****

! Open Issues
! ===========

 * Should *tuple* objects be included? In the past, they have been
! denied some list like behaviors such as count() and index().

 * Should *file* objects be included? Implementing reverse iteration
! may not be easy though it would be useful on occasion.

 * Should *enumerate* objects be included? They can provide reverse
 iteration only when the underlying sequences support *__len__*
! and reverse iteration.

--- 73,91 ----

! Other Issues
! ============

 * Should *tuple* objects be included? In the past, they have been
! denied some list like behaviors such as count() and index(). I
! prefer that it be included.

 * Should *file* objects be included? Implementing reverse iteration
! may not be easy though it would be useful on occasion. I think
! this one should be skipped.

 * Should *enumerate* objects be included? They can provide reverse
 iteration only when the underlying sequences support *__len__*
! and reverse iteration. I think this can be saved for another
! day if the need arises.

***************
*** 105,109 ****
 and clearer with::

! for func, target, kargs in _exithandlers.ireverse():
 . . .
 del _exithandlers
--- 107,111 ----
 and clearer with::

! for func, target, kargs in _exithandlers.iterreverse():
 . . .
 del _exithandlers
***************
*** 132,136 ****

 result.sort()
! return [x for score, x in result[-n:].ireverse()]

 * heapq.heapify() uses ``for i in xrange(n//2 - 1, -1, -1)`` because
--- 134,138 ----

 result.sort()
! return [x for score, x in result[-n:].iterreverse()]

 * heapq.heapify() uses ``for i in xrange(n//2 - 1, -1, -1)`` because
***************
*** 159,163 ****
 be run in a forward direction but is less intuitive and rarely
 presented that way in literature. The replacement code
! ``for i in xrange(1, len(x)).ireverse()`` is much easier
 to mentally verify.

--- 161,165 ----
 be run in a forward direction but is less intuitive and rarely
 presented that way in literature. The replacement code
! ``for i in xrange(1, len(x)).iterreverse()`` is much easier
 to mentally verify.

***************
*** 197,201 ****
 The last variant can invisibly slip into a low performance mode
 (in terms of time and memory) which could be made more visible with
! an explicit ``list(obj).reverse()``.

--- 199,203 ----
 The last variant can invisibly slip into a low performance mode
 (in terms of time and memory) which could be made more visible with
! an explicit ``ro=list(obj); ro.reverse()``.