On Wednesday 05 November 2003 03:54 pm, Phillip J. Eby wrote: ... > >reverse iteration. The iterator object has no way of knowing in advance > >that it is going to be called by reversed(). > > Why not change enumerate() to return an iterable, rather than an > iterator? Then its __reversed__ method could attempt to delegate to the > underlying iterable. Is it likely that anyone relies on enumerate() being > an iterator, rather than an iterable? I do rely on the _argument_ of enumerate being allowed to be just any iterator, yes -- e.g. in such idioms as: for i, x in enumerate(xs): if isgoodenough(x): return x elif istoohigh(i): raise GettingBoredError, i Yes, I _could_ recode that as: i = 0 for x in xs: if isgoodenough(x): return x i += 1 if istoohigh(i): raise GettingBoredError, i but, I don't _wanna_...:-). enumerate is just too slick! Of course, it would be fine for reverse(enumerate(x)) to fail for unsuitable values of x -- that's a separate issue. But actually it would not be a tragedy if I couldn't reverse(enumerate -- e.g. where I'd LIKE to code: for i, x in reverse(enumerate(xs)): if isbad(x): raise BadXError, x xs[i] = transform(x) I _might_ reasonably code: for i, x in enumerate(reverse(xs)): if isbad(x): raise BadXError, x xs[-1-i] = transform(x) that -1-i may not be the prettiest sight in the world, but I think this STILL beats the alternative of: for i in reversed_range(len(xs)): x = xs[i] if isbad(x): raise BadXError, x xs[i] = transform(x) not to mention today's for i in xrange(-1, -len(xs)-1, -1): x = xs[i] if isbad(x): raise BadXError, x xs[i] = transform(x) or: for i in xrange(len(xs)-1, -1, -1): x = xs[i] if isbad(x): raise BadXError, x xs[i] = transform(x) Alex
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