[Python-checkins] python/nondist/peps pep-0322.txt,1.1,1.2

[rhettinger at users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv11222

Modified Files:
	pep-0322.txt 
Log Message:
Updated to reflect comments on comp.lang.python.

Index: pep-0322.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0322.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** pep-0322.txt	24 Sep 2003 10:30:08 -0000	1.1
--- pep-0322.txt	25 Sep 2003 16:18:28 -0000	1.2
***************
*** 30,35 ****
  One other current approach involves reversing a list before iterating
  over it.  That technique wastes computer cycles, memory, and lines of
! code.  Also, it only works with lists (strings, for example, do not
! define a reverse method)::
  
      rseqn = list(seqn)
--- 30,34 ----
  One other current approach involves reversing a list before iterating
  over it.  That technique wastes computer cycles, memory, and lines of
! code::
  
      rseqn = list(seqn)
***************
*** 38,43 ****
          print value
  
! Extending slicing minimizes the code overhead but does nothing for
! memory efficiency, beauty, or clarity.
  
  Reverse iteration is much less common than forward iteration, but it
--- 37,42 ----
          print value
  
! Extending 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
***************
*** 110,113 ****
--- 109,115 ----
      del _exithandlers
  
+   Note, if the order of deletion is important, then the first form
+   is still needed.
+ 
  * difflib.get_close_matches() uses::
  
***************
*** 150,159 ****
    ``for n in range(len(verfiles)-1,-1,-1)`` because the loop deletes
    selected elements from *verfiles* but needs to leave the rest of
!   the list intact for further iteration.  This use case could be
!   addressed with *itertools.ifilter()* but would require the
!   selection predicate to be in a *lambda* expression.  The net
!   result is less clear and readable than the original.  A better
!   reformulation is to replace the first line with the proposed
!   method.
  
  * random.shuffle() uses ``for i in xrange(len(x)-1, 0, -1)`` because
--- 152,156 ----
    ``for n in range(len(verfiles)-1,-1,-1)`` because the loop deletes
    selected elements from *verfiles* but needs to leave the rest of
!   the list intact for further iteration.
  
  * random.shuffle() uses ``for i in xrange(len(x)-1, 0, -1)`` because
***************
*** 161,165 ****
    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.
  
  * rfc822.Message.__delitem__() uses::
--- 158,164 ----
    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
!   to mentally verify.
  
  * rfc822.Message.__delitem__() uses::
***************
*** 173,193 ****
  
  
! Rejected Alternative Ideas
! ==========================
  
! * Add a builtin function, *reverse()* which calls a magic method,
!   __riter__.  I see this as more overhead for no additional benefit.
  
! * Add a builtin function, *reverse()* which does the above, and
!   if *__riter__* is not found, constructs its own using
!   *__getitem__*, and if *__getitem__* is not found, builds a list
!   from *__iter__* and returns a reverse iterator over the new list.
!   The advantage is that one function takes care of almost everything
!   that is potentially reversible.  A disadvantage is that it can
!   invisibility slip in to a low performance mode (in terms of time
!   and memory) which would be more visible with an explicit
!   ``list(obj).reverse()``.  Another problem is that *__getitem__*
!   is also used in mappings as well as sequences and that could lead
!   to bizarre results.
  
  
--- 172,201 ----
  
  
! Alternative Ideas
! =================
  
! * Add a builtin function, *riter()* which calls a magic method,
!   *__riter__*.  I see this as more overhead for no additional benefit.
  
! * Several variants were submitted that provided fallback behavior
!   when *__riter__* is not defined:
! 
!   - fallback to:  ``for i in xrange(len(obj)-1,-1,-1): yield obj[i]``
!   - fallback to:  ``for i in itertools.count(): yield[obj[-i]]``
!   - fallback to:  ``tmp=list(obj); tmp.reverse();  return iter(tmp)``
! 
!   All of these attempt to save implementing some object methods at the
!   expense of adding a new builtin function and of creating a new magic
!   method name.
! 
!   The approaches using *__getitem__()* are slower than using a custom
!   method for each object.  Also, the *__getitem__()* variants produce
!   bizarre results when applied to mappings.
! 
!   All of the variants crash when applied to an infinite iterator.
! 
!   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()``.