> > >The __reversed__ protocol muddles the issue by inviting to
> > > try to make reversed() work for some iterators
>
> The invitation is to add efficient reverse iteration support to regular
> objects and user defined classes, not for iterators. Though I won't be
> suprised if someone tries, the only iterator that has a chance with this
> is enumerate, but that is not what the hook is for.
Yeah, but there was widespread misunderstanding here (for a while even
you and Alex were convinced that it was possible for enumerate).
Several functions in itertools could easily be made to support
__reversed__ *if* their argument supports it (or even if not in one
case):
chain(*iterables) -- you can define reversed(chain(*iterables)) as
follows:
for it in reversed(iterables):
for element in reversed(it):
yield element
cycle(iterable) -- this one is infinite but reversed(cycle(x)) could be
defined as cycle(reversed(x)).
ifilter(pred, it) -- again, it's easy to define reversed(ifilter(P, X))
as ifilter(P, reversed(X)). Ditto for ifilterfalse.
imap() -- this would not be so easy because the iterables might not be
of equal length, so you can't map reversed(imap(F, X, Y)) to imap(F,
reversed(X), reversed(Y)). But for a single sequence, again it could be
done.
islice() -- seems easy enough.
starmap() -- simple, this is like imap() with a single argument.
repeat() -- trivial! reversed(repeat(X[, N])) == repeat(X[, N]).
dropwhile(), takewhile(), count() aren't amenable.
So, unless you want to open this can of worms, I'd be for a version of
reversed() that does *not* support __reversed__, making it perfectly
clear it only applies to real sequences.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4