Guido van Rossum wrote: >>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. > > > It's more effort to add something later than to remove it (since > there's always *someone* who's already dependent on it), so I see the > argument about adding __reversed__ far from balanced. I see at most a > 5% chance that reversed() would be removed before 2.3b1. If we add > __reversed__ now I doubt that we'll remove it (assuming reversed() > stays), but I still am unconvinced of the need (and I *am* convinced > of the danger). > > So: > > - I am +1 on adding reversed() provisionally > - I am -1 on adding __reversed__ at the same time > Been following this from afar (crazy week with homework; fun). In case anyone cares about my opinion: +0 on reversed(): wouldn't hurt having it but I still don't see it as critical enough to be a built-in -1 on __reversed__: I like my iterator protocol **simple**. OK, back to studying for my midterm. -Brett
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