«

Based on your extensive feedback, PEP 322 has been completely revised.
The response was strongly positive, but almost everyone preferred
having a function instead of multiple object methods. The updated
proposal is at:

www.python.org/peps/pep-0322.html

In a nutshell, it proposes a builtin function that greatly simplifies reverse
iteration. The core concept is that clarity comes from specifying a
sequence in a forward direction and then saying, "inreverse()":

for elem in inreverse(seqn):
. . .

Unlike seqn[::-1], this produces a fast iterator instead of a full reversed
copy.

Discussions with Guido made it clear that inreverse() will not be extended
to cover all iterables. The proposal is about simplicity, expression, and
performance. As such, it would be counter-productive to take in a general
iterable, run it to completion, save the data in memory, and then iterate
over the data in reverse.


Raymond Hettinger

Raymond Hettinger wrote:

>
> Discussions with Guido made it clear that inreverse() will not be extended
> to cover all iterables. The proposal is about simplicity, expression, and
> performance. As such, it would be counter-productive to take in a general
> iterable, run it to completion, save the data in memory, and then iterate
> over the data in reverse.
>

Which of course can easily be done explicitely:

# Make some iterable unsuitable for inreverse
a = iter("Hello")

# Create a list that can be in'reversed explicitely
for i in inreverse(list(a)):
print i


As always, explicit is better than implicit

Maybe something alike should go into the docs...


- Werner

Hi,

was it considered to name the function just "reverse"?

This would read very naturally to me:

for elem in reverse(seq):
print elem


Also if you use it in function calls it looks good to me:

x = dostuff(reverse(seq), a, b)


Another possibility would be to have a static method for iter:

for elem in iter.reversed(sed):
print elem

(in that case I'd use an attribute rather than a verb, because
the generated iter(ator) will be reverse_d_).

The static method approach would clearly document that the
result is an iterator (which none of the other names proposed
really does IMHO)


In general, I'm +1 on the PEP


regards

Werner

(Raymond Hettinger) writes:

> In a nutshell, it proposes a builtin function that greatly simplifies reverse
> iteration. The core concept is that clarity comes from specifying a
> sequence in a forward direction and then saying, "inreverse()":
>
> for elem in inreverse(seqn):
> . . .

I've got to say, I really don't like the name. Particularly, the
repeated "in" in "in inreverse..." strikes me as ugly.

> Discussions with Guido made it clear that inreverse() will not be extended
> to cover all iterables. The proposal is about simplicity, expression, and
> performance. As such, it would be counter-productive to take in a general
> iterable, run it to completion, save the data in memory, and then iterate
> over the data in reverse.

I like the proposal, it's simple and expressive. But please, change
the name! I assume there's a good reason why the obvious "reverse()"
wasn't chosen. Of the alternatives in the PEP, backwards() doesn't
seem to read nicely (but it's better than inreverse!!!), and ireverse
is OK, but makes me think that it should be in itertools (or all the
itertools should be builtin). Some other possibilities:

rev(seq) - probably too abbreviated
reversed(seq) - adjective rather than verb, but reads well

As usual, the semantics is perfectly acceptable, but we'll have a nice
long argument over the name

Paul.
--
This signature intentionally left blank

Werner Schiendl wrote:
...
> Another possibility would be to have a static method for iter:
>
> for elem in iter.reversed(sed):
> print elem
>
> (in that case I'd use an attribute rather than a verb, because
> the generated iter(ator) will be reverse_d_).
>
> The static method approach would clearly document that the
> result is an iterator (which none of the other names proposed
> really does IMHO)

I like this one! Another advantage is, one fewer built-in.

Problem is, iter is currently a built-in function, not a type...


Alex

+1


"Raymond Hettinger" <> wrote in message
news: om...
> Based on your extensive feedback, PEP 322 has been completely revised.
> The response was strongly positive, but almost everyone preferred
> having a function instead of multiple object methods. The updated
> proposal is at:
>
> www.python.org/peps/pep-0322.html
>
> In a nutshell, it proposes a builtin function that greatly simplifies
reverse
> iteration. The core concept is that clarity comes from specifying a
> sequence in a forward direction and then saying, "inreverse()":
>
> for elem in inreverse(seqn):
> . . .
>
> Unlike seqn[::-1], this produces a fast iterator instead of a full
reversed
> copy.
>
> Discussions with Guido made it clear that inreverse() will not be extended
> to cover all iterables. The proposal is about simplicity, expression, and
> performance. As such, it would be counter-productive to take in a general
> iterable, run it to completion, save the data in memory, and then iterate
> over the data in reverse.

It's certainly clear enough, and I like it in general.

I'd appreciate a bit of discussion about why reverse() was rejected as
the name, though.

John Roth
>
>
> Raymond Hettinger

In article < >, Raymond Hettinger wrote:
> for elem in inreverse(seqn):
> . . .

Is there an echo in inhere? +1 +1otherwise... =)

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :

Raymond Hettinger wrote:

> Based on your extensive feedback, PEP 322 has been completely revised.

Personally, for some tasks I have used reverse iteration quite a bit.

My use case has _always_ been that I want to modify a list (e.g.
adding or deleting items) in situ. In all other cases which I can
recall, I have quite happily iterated in the forward direction.

(Maybe this is because I am not afraid to call list.reverse(), and
insertion/deletion is the only use case where this doesn't really help.)

This means that the implementation restrictions described in the PEP are
fine with me (because a list has the requisite methods).

However, this also means that I am most interested in how the enumerate()
interface will work with this (because the current list index must be
known in order to properly add or delete items). enumerate() was
mentioned in the PEP but not discussed in any real depth.

My personal preference (since this is the only use case which I have
ever encountered) would be to enhance enumerate in a reasonable fashion,
and not necessarily even have (or at least care about) the reverse/ireverse/
whatever name underneath enumerate().

I will happily accept whatever syntax comes along (unless the enumerate
counts 0,1,2,3... while the index of the adjacent list object is decremented
[-1],[-2],[-3]...

BUT, for sheer usability I think it would be wonderful if enumerate()
took an optional second argument to let it know you want to go backward.
The most general syntax for this second argument would naturally be
a slice:

for idx,obj in enumerate(mylist,-1:-1:-1):
do whatever

but if people think this is too ugly something simpler could be
substituted (but think about the useful possibilities of a slice
argument here before you complain too hard about the ugliness...)

Some may argue that this restricts enumerate() to certain kinds of
iterators when using the slice (and thus adds a lot of special casing),
but it may be that, realistically, if ireverse() is going to have this
special casing, and enumerate() is going to work with ireverse(), you
already have the same problem (unless the user is expected to work
with the enumerate counting backwards from the actual list index).
I cannot say this for sure, however, because I did not see (or perhaps
read closely enough) the part of the PEP which discussed enumerate.

Regards,
Pat

Alex Martelli wrote:
> Werner Schiendl wrote:
> ...
>>Another possibility would be to have a static method for iter:
>>
>>for elem in iter.reversed(sed):
>> print elem
>>
>
> I like this one! Another advantage is, one fewer built-in.
>
> Problem is, iter is currently a built-in function, not a type...
>

An additional advantage that came to my mind is that it would fit
Guido's preference about how to (possible) implement inline sort.

having

L = list.sorted(seq)

i = iter.reversed(seq)

seems very consistent to me.


best regards

Werner

> The static method approach would clearly document that the
> result is an iterator (which none of the other names proposed
> really does IMHO)

Better name are welcome!

Moving it somewhere else is not open. It is proposed as a builtin for a
reason -- it is a core looping tool like zip() or enumerate() and it is meant
to simplify rather than complicate code.

Static methods, class methods, and weird descriptors be darned, this is
not an exercise in how weirdly it can be implemented just to avoid
having a builtin.

Would everything be somehow better if Alex's wonderful sum() had
been implemented as a int.sum() classmethod or was tucked way in
another module? Of course not! Likewise, would zip() or enumerate()
be successful solutions to lock-step iteration and the loop-counter
problems if they were iter.zip() and iter.enumerate()? No, of course not.
Let's put an end to this silliness right now. The idea is offered as a
builtin or not at all; otherwise, the existing [::-1] starts to look better.


> In general, I'm +1 on the PEP

Thanks! I certain it will make code more readable and reviewable.

The challenge with a PEP this simple is that experts feel this
overpowering urge to apply all their know-how and transform
in to something other than a clean, fast, simple solution.


Raymond Hettinger