> We have a problem here, but I think it's in the fact that > currently certain slices end up in __getitem__ and some in > __getslice__. > > IOW, I think that __getitem__ should return an item, and this > fix (while clever) just compounds a mistake. Agreed in an ideal world, but it's done like this for backwards compatibility. The proper solution would be for __getslice__ to always get the raw values given to the slice, but so that __getslice__ takes an optional third argument which gets the 3rd slice value if present. So x[i:j] results in x.__getslice__(i,j) while x[i:j:k] results in x.__getslice__(i,j,k). Missing values are replaced with None, so that x[:] results in x.__getslice__(None, None) and x[::] in x.__getslice__(None, None, None). This is pretty backwards incompatible! Perhaps to the devil with b/w compat? Note that C extensions also get too much service for slicing. It seems a somewhat tedious project to clean all of this up... --Guido van Rossum (home page: http://dinsdale.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