Rename the proposal to ireverse().

pep-0322.txt

@@ -46,15 +46,15 @@ does arise regularly in practice.  See `Real World Use Cases`_ below.
 Proposal
 ========
 
-Add a method called *iter_backwards()* to sequence objects that can
+Add a method called *ireverse()* to sequence objects that can
 benefit from it.  The above examples then simplify to::
 
-    for i in xrange(n).iter_backwards():
+    for i in xrange(n).ireverse():
         print seqn[i]
 
 ::
 
-    for elem in seqn.iter_backwards():
+    for elem in seqn.ireverse():
         print elem
 
 The new protocol would be applied to lists, strings, xrange objects,
@@ -104,7 +104,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.iter_backwards():
+    for func, target, kargs in _exithandlers.ireverse():
         . . .
     del _exithandlers
 
@@ -131,7 +131,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:].iter_backwards()]
+      return [x for score, x in result[-n:].ireverse()]
 
 * 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 +158,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)).iter_backwards()`` is much easier
+  ``for i in xrange(1, len(x)).ireverse()`` is much easier
   to mentally verify.
 
 * rfc822.Message.__delitem__() uses::