[Python-ideas] Where did we go wrong with negative stride?

[Paul Moore]

On 29 October 2013 18:08, MRAB <python at mrabarnett.plus.com> wrote:
> On 29/10/2013 10:23, Paul Moore wrote:
>>
>> On 28 October 2013 22:41, Guido van Rossum <guido at python.org> wrote:
>>>
>>> I'm not sure I like new syntax. We'd still have to find a way to
>>> represent
>>> this with slice() and also with range().
>>
>>
>> It's a shame there isn't an indexing syntax where you can supply an
>> iterator that produces the set of indexes you want and returns the
>> subsequence - then we could experiment with alternative semantics in
>> user code.
>>
>> So, for example (silly example, because I don't have the time right
>> now to define an indexing function that matches any of the proposed
>> solutions):
>>
>>      >>> def PrimeSlice():
>>      >>>    yield 2
>>      >>>    yield 3
>>      >>>    yield 5
>>      >>>    yield 7
>>
>>      >>> 'abcdefgh'[[PrimeSlice()]]
>>      'bceg'
>>
>> But of course, to make this user-definable needs new syntax in the
>> first place :-(
>>
> We already use (...) and [...], which leaves {...}:
>
>>>> 'abcdefgh'{PrimeSlice()}
> 'bceg'


You could probably do it by simply adding an extra case to __getitem__
on builtin types: check in order for integer/object with __index__
(single index), Slice object (traditional slice), iterable (series of
arbitrary indices). User defined types would have to implement this in
the same way that they currently have to implement Slice behaviour,
and dictionaries would not behave the same (again, in the same way as
for Slice).

Basically an iteravble doesn't need to be any more of a special case
than Slice (in fact Slice is *more* special, because there is syntax
that generates Slice objects).

Paul