[Python-ideas] List indexing multiple elements
Paul Moore
p.f.moore at gmail.com
Mon Feb 20 17:12:37 EST 2017
On 20 February 2017 at 20:54, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> Apologies if this has already been covered!
>
> Right now, if you want to get multiple elements in a list, you have to do:
>
> elements = [mylist[a], mylist[b]]
>
> My proposal is two-folded:
>
> - Right now, a[b,c] is already valid syntax, since it's just indexing a with
> the tuple (b, c). The proposal is to make this a specialization in the
> grammar, and also allow stuff like a[b:c, d:e] (like `a.__getitem__(slice(b,
> c), slice(d, e))`).
I'm not sure what you mean by a "specialisation in the grammar". This
is currently valid syntax. It's only list.__getitem__ that rejects it:
>>> lst[4:5,6]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: list indices must be integers or slices, not tuple
That error comes from lst.__getitem__, not from the grammar.
> - Add support for indexing via tuples in list.__getitem__.
> list.__getitem__(tuple) would roughly be equivalent to map(list.__getitem__,
> tuple).
>
> The first part is solely so that slices would be allowed in the syntax, but
> if you guys don't like the idea, the second part still stands.
But they already are...
> Thoughts? *ducks from flying tomatoes*
Thoughts on the second path, then.
I presume you're aware this can be done right now using a helper
function. And indeed you point out yourself that it's basically
map(lst.__getitem__, seq). So I guess the key question is what
*additional* benefit do you see to this proposal that justifies adding
it to the builtin list type *now*, when people have managed fine this
far without it.
Paul
More information about the Python-ideas
mailing list