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()``.