(I changed the subject) > When I was going through the sources of sliceobject.c I found the function > PySlice_GetIndicesEx. It performs the magic of trimming a slice into the > range of indices of a sequence, including negative indices and intervals > with None as start or stop value. A comment in this function says: > > /* this is harder to get right than you might think */ > > Wouldn't it be a good idea to expose this nontrivial functionality to > Python code as a method of slice objects? I dunno. It seems that most code that actually uses slices is written in C anyway. > The method would take an integer argument (length) and return an > xrange object. Why an xrange object? That's not inspectable. *If* we were to do this (which I doubt) it should return a tuple of three ints. > It should make it much > easier to implement user types that support extended slicing: > > def __getitem__(self, index): > if isinstance(index, slice): > return [get_item_at(i) for i in index.trim(len(self))] > else: > return get_item_at(index) > > Suggestions for a better name than trim? getindices() > Any reason why this API should stay exposed only to C and not to > Python? Have you got a real use case? I'm a bit weary of hypothetical use cases (that's what got us xrange repetition in the first place). --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