> but is still an hybrid, setting a bad precedent of trying too hard to > attach __reversed__ to an iterator, making enumerate just an iterable is > not backward compatible but is a bit saner although it does not feel that > natural either. Exactly. All I've heard is that some folks asked for __reversed__. I haven't heard any convincing use cases; the PEP doesn't have any. The only motivation in the PEP is this: """ Custom Reverse Objects may optionally provide a __reversed__ method that returns a custom reverse iterator. This allows reverse() to be applied to objects that do not have __getitem__() and __len__() but still have some useful way of providing reverse iteration. """ To me, this just *begs* for attempts to add __reversed__ to all sorts of things (including iterators) that aren't sequences. If the real use case is to speed up performance, I'd like to see a discussion of the attainable speed gain, and I'd like to see the absence of __getitem__ / __len__ removed from the motivation. --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