> I do think that the savings in typing from having a reverse= keyword > for that one use case are easily outnumbered by the extra typing for > the much more common use case that has reverse=True. > > But really, I could live with either one, so Raymond can decide based > upon the evidence, and as I said, either way having this in itertools > is an argument against making reversed() a builtin. Candidate itertools are expected to accept general iterables as inputs and to work well with each other. This function accepts only sequences as inputs and cannot handle outputs from other itertools. IOW, it doesn't belong in the toolset. As proposed, the reversed() function is much more general than a backwards xrange. Handling any sequence is a nice plus and should not be tossed away. I would like reversed() to be usable anywhere someone is tempted to write seq[::-1]. reversed() is a fundamental looping construct. Tucking it away in another module in not in harmony with having it readily accessible for everyday work. Having dotted access to the function makes its use less attractive. My original proposal was to have methods attached to a few sequence types. I was deluged with mail pushing toward a more universal builtin function and that's what is on the table now. There have been many notes of support but their voices have been partially drowned by naming discussions and some weird ideas on places to put it. I do not support putting it in another namespace, turning it into a keyword argument, or making it into yet another version of xrange. What's out there now is simple and direct. Everyone, please accept it as is. Raymond Hettinger
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