* Rename the proposed method to "iterreverse"

* Make recommendations on the open issues.
* Minor wording changes.

pep-0322.txt

@@ -36,7 +36,7 @@ code::
     for value in rseqn:
         print value
 
-Extending slicing is a third approach that minimizes the code overhead
+Extended slicing is a third approach that minimizes the code overhead
 but does nothing for memory efficiency, beauty, or clarity.
 
 Reverse iteration is much less common than forward iteration, but it
@@ -46,21 +46,20 @@ does arise regularly in practice.  See `Real World Use Cases`_ below.
 Proposal
 ========
 
-Add a method called *ireverse()* to sequence objects that can
+Add a method called *iterreverse()* to sequence objects that can
 benefit from it.  The above examples then simplify to::
 
-    for i in xrange(n).ireverse():
+    for i in xrange(n).iterreverse():
         print seqn[i]
 
 ::
 
-    for elem in seqn.ireverse():
+    for elem in seqn.iterreverse():
         print elem
 
-The new protocol would be applied to lists, strings, xrange objects,
+The new protocol would be applied to lists, tuples, strings, and
-and possibly other sequence objects as well (depending on use cases
+xrange objects.  It would not apply to unordered collections like
-and implementation issues).  It would not apply to unordered
+dicts and sets.
-collections like dicts and sets.
 
 No language syntax changes are needed.
 
@@ -73,18 +72,21 @@ Alternative Method Names
 * *ireverse* -- reminiscent of imap(), izip(), and ifilter()
 
 
-Open Issues
+Other Issues
-===========
+============
 
 * Should *tuple* objects be included?  In the past, they have been
-  denied some list like behaviors such as count() and index().
+  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.
+  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.
+  and reverse iteration.  I think this can be saved for another
+  day if the need arises.
 
 
 Real World Use Cases
@@ -104,7 +106,7 @@ library and comments on why reverse iteration was necessary:
   form is readable and clean; however, it would be slightly faster
   and clearer with::
 
-    for func, target, kargs in _exithandlers.ireverse():
+    for func, target, kargs in _exithandlers.iterreverse():
         . . .
     del _exithandlers
 
@@ -131,7 +133,7 @@ library and comments on why reverse iteration was necessary:
   The proposed form is much easier to construct and verify::
 
       result.sort()
-      return [x for score, x in result[-n:].ireverse()]
+      return [x for score, x in result[-n:].iterreverse()]
 
 * heapq.heapify() uses ``for i in xrange(n//2 - 1, -1, -1)`` because
   higher-level orderings are more easily formed from pairs of
@@ -158,7 +160,7 @@ library and comments on why reverse iteration was necessary:
   elements from an ever diminishing pool.  In fact, the algorithm can
   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
+  ``for i in xrange(1, len(x)).iterreverse()`` is much easier
   to mentally verify.
 
 * rfc822.Message.__delitem__() uses::
@@ -196,7 +198,7 @@ Alternative Ideas
 
   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()``.
+  an explicit ``ro=list(obj); ro.reverse()``.
 
 
 Copyright