> > I'm okay with adding reversed() as a builtin that works for sequences > > only but I'm not okay with adding the __reversed__ protocol. > > But, doesn't this effectively take the PEP back to the original proposal > of a sequence method that it drifted away from? No, because making it a sequence method would require every sequence implementation to support it. Making it a builtin makes it work for all sequences (everything that supports __len__ and __getitem__ with random access, really). > With the restriction to sequences, reversed() is then likely to be > implemented as a thin wrapper around seq.somerevmethod() which could then > return either a new reversed sequence, an iterable, or an iterator > depending upon efficiency, implementation, thread-safety, etc. No. reversed() should *never* return a new sequence; it should return an iterator. > Since reversed() is turning out not be generally applicable anyway, > perhaps going back to the original idea of a sequence method would be a > good thing? No. The feedback on that was pretty uniformly negative. The PEP is 95% about reversed() on sequences and only a timy bit about __reversed__, so little is lost. --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