From cec064b24f135a9068730d6e433aefd9ebb3f8eb Mon Sep 17 00:00:00 2001 From: Raymond Hettinger Date: Sun, 28 Sep 2003 02:43:37 +0000 Subject: [PATCH] * Rename the proposed method to "iterreverse" * Make recommendations on the open issues. * Minor wording changes. --- pep-0322.txt | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/pep-0322.txt b/pep-0322.txt index 39699174c..8a35efddc 100644 --- a/pep-0322.txt +++ b/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, -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. +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. @@ -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