On 29 October 2013 18:08, MRAB <python@mrabarnett.plus.com> wrote:
On 29/10/2013 10:23, Paul Moore wrote:
On 28 October 2013 22:41, Guido van Rossum <guido@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