> I'm not married to the idea of __reversed__ but think it should > probably be kept (if my intuition is off on this one, we can pull it > out before the beta release). Let's do it the other way around -- let's not add a complication until we have further proof it is needed. Remember YAGNI. :-) > On the plus side: > > * Many of the original posters either specifically requested this or > included some variation of it in their proposals. If any of them gave a good motivation or use case, those didn't make it into the PEP. > * There is a small group (including Jeremy Fincher) that consider a > reversal protocol to be essential. And I think that as a protocol it needs a separate PEP, because new protocols are much more involved than new builtins. > * It is particularly useful for xrange() because it reduces the overhead > to zero without touching the API. The implementation patch on SF shows > that this can be done cleanly. Essentially, __reverse__ forwards the > call to __iter__ with the arguments rearranged for reverse order. The implementation could special-case xrange() and lists and "optimize the snot out of them" without the need for a general protocol. > * It leaves open the possibility that someone could add __reverse__ to > file objects, enabling them loop in reverse (helpful in reviewing log > files for example). That's exactly the danger. Such a thing is much better coded as a separate object rather than adding it to the base file object. > * There is a small group that passionately wants reverse() to work with > enumerate() and Alex appears to be close to figuring out how to overcome > the implementation challenges. Doubtful. > * The iter/__iter__ pair neatly parallels reversed/__reversed__. The parallel is a fallacy (see one of my previous postys about the asymmetry). > * It is pythonic to put hooks in for just about everything. Sooner or > later, someone needs the hook. For everyone else, it's invisible. But hook design is harder than builtin design. > On the minus side: > > * I think you got cold feet when some poster presented a wacky or > misguided use for it. There's no avoiding that; even Alex's dirt simple > __copy__ protocol can be turned into an atrocity by someone so inclined. The __copy__ protocol is limited in practice to the expectations and promises of the copy module. The problem with __reversed__ is that everyone thinks it means what *they* would like to see. > are-your-feet-feeling-warmer-now-ly yours, No, this is one of the coldest weeks since my mvoe to Calif. :-) --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