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/