On Wednesday 05 November 2003 23:21, Guido van Rossum wrote: > > > >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). It _is_ *possible*; it is not necessarily _opportune_ -- a different issue. Similarly, you point out below possibilities that may not be opportune. > 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. Unless some _opportune_ (i.e., truly good:-) use case of "naturally reversible nonsequence" (doubly linked list...?-) arises (and the __reversed__ idea can inserted then -- just as it could be removed if reversed started out with it -- as long as we do it before the beta) reversed with or without __reversed__ seem anyway fine to me -- arguments being so finely balanced on both sides. 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