No one likes the name inreverse().

pep-0322.txt

@@ -46,27 +46,27 @@ does arise regularly in practice.  See `Real World Use Cases`_ below.
 Proposal
 ========
 
-Add a builtin function called *inreverse()* that makes a reverse
+Add a builtin function called *ireverse()* that makes a reverse
 iterator over sequence objects that support __getitem__() and
 __len__().
 
 The above examples then simplify to::
 
-    for i in inreverse(xrange(n)):
+    for i in ireverse(xrange(n)):
         print seqn[i]
 
 ::
 
-    for elem in inreverse(seqn):
+    for elem in ireverse(seqn):
         print elem
 
 The core idea is that the clearest, least error-prone way of specifying
 reverse iteration is to specify it in a forward direction and then say
-*inreverse*.
+*ireverse*.
 
 The implementation could be as simple as::
 
-    def inreverse(x):
+    def ireverse(x):
         i = len(x)
         while i > 0:
             i -= 1
@@ -83,13 +83,16 @@ Alternative Method Names
 ========================
 
 * *backwards* -- more pithy, less explicit
-* *ireverse* -- reminiscent of imap(), izip(), and ifilter()
+* *inreverse* -- no one seems to like this one except me
+
+The name *reverse* is not a candidate because it duplicates the name
+of the list.reverse() which mutates the underlying list.
 
 
 Custom Reverse
 ==============
 
-Objects may optionally provide an *__inreverse__* method that returns
+Objects may optionally provide an *__ireverse__* method that returns
 a custom reverse iterator.
 
 This allows reverse() to be applied to objects that do not have 
@@ -140,7 +143,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 inreverse(xrange(1, len(x)))`` is much easier
+  ``for i in ireverse(xrange(1, len(x)))`` is much easier
   to verify visually.
 
 * rfc822.Message.__delitem__() uses::
@@ -158,7 +161,7 @@ Active Alternative
 
 A simpler, but limited alternative is to create a builtin that takes
 the same arguments as range() but returns a reverse iterator over the
-range.  The idea is that much of the benefit of inreverse() comes
+range.  The idea is that much of the benefit of ireverse() comes
 reducing the intellectual effort it takes to express the arguments for
 [x]range() when going backwards.  A good name is needed for this
 alternative -- revrange() is cleanest so far.
@@ -167,7 +170,7 @@ alternative -- revrange() is cleanest so far.
 Rejected Alternative
 ====================
 
-Several variants were submitted that attempted to apply inreverse()
+Several variants were submitted that attempted to apply ireverse()
 to all iterables by running the iterable to completion, saving the
 results, and then returning a reverse iterator over the results.
 While satisfying some notions of full generality, running the input