On PEP 322 (ireverse)

[Raymond Hettinger]

[Terry Reedy]
> Any good reason not to make iter so?  int, str, and float were once
> bifs also.

The C code for it has a split path, calling __iter__ for objects that
have it, building iterator wrappers for sequences that don't have
__iter__, or building another wrapper when the inputs are a
function and sentinel.  IOW, it is a factory function capable
of constructor any of several different types.

> I'm +1 on iter.reversed, along with list.sorted.

Please no.

list.sorted() is entirely unrelated.  It is attached to lists because that
is what it generally returns and because its functionality is closely
tied to list.sort().  It is a class method because that gave it
richer functionality by taking any iterable as an argument:

    list.sorted('a string').

When I posted the PEP for comment, I was looking for confirmation
that the underlying problem is real and for folks to look through their
own code to see if the proposed solution truly offered improvements
in terms of clarity and performance.

Grafting this onto iter is not an option; I would rather lose the
functionality than have the experts here twist it into something
I can't easily explain to a client.


Raymond Hettinger