On 20 February 2017 at 20:54, Ryan Gonzalez <rym...@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to