[Python-ideas] PEP pre-draft: Support for indexing with keyword arguments

[Stephan Hoyer]

 don't have strong opinions about the implementation, but I am strongly 
supportive of this PEP for the second case it lists -- the ability to index 
an a multi-dimensional array by axis name or label instead of position.

Why? Suppose you're working with high dimensional data, where arrays may 
have any number of axes such as time, x, y and z. I work with this sort of 
data every day, as do many scientists.

It is awkward and error prone to use the existing __getitem__ and 
__setitem__ syntax, because it's difficult to reliably keep track of axis 
order with this many indices:

a[:, :, 0:10]

vs.

a[y=0:10]

Keyword getitem syntax should be encouraged for the same reasons that 
keyword arguments are often preferable to positional arguments: it is both 
explicit (no implicit reliance on axis order), and more flexible (the same 
code will work on arrays with transposed or altered axes). This is 
particularly important because it is typical to be working with arrays that 
use some but not all the same axes.

A method does allow for an explicit (if verbose) alternative to __getitem__ 
syntax:

a.getitem(y=slice(0, 10))

But it's worse for __setitem__:

a.setitem(dict(y=slice(0, 10)), 0)

vs.

a[y=0:10] = 0

------------

Another issue: The PEP should address whether expressions with slice 
abbreviations like the following should be valid syntax:

a[x=:, y=:5, z=::-1]

These look pretty strange (=: looks like a form of assign), but the 
functionality would certainly be nice to support in some way.

Surrounding the indices with [] might help:

a[x=[:], y=[:5], z=[::-1]]

-------------


On Thursday, July 3, 2014 12:39:09 AM UTC-7, Bruce Leban wrote:
>
> Tangentially, I think the PEP can reasonably reserve the keyword argument 
> name 'default' for default values specifying that while __getitem__ methods 
> do not need to support default, they should not use that keyword for any 
> other purpose.
>

-1 from me. The existing get method handles this case pretty well, with 
fewer keystrokes than the keyword only "default" index (as I think has 
already been pointed out).

In my opinion, case 1 (labeled indices for a physics DSL) and case 2 
(labeled indices to removed ambiguity) are basically the same, and the only 
use-cases that should be encouraged. Labeling tensor indices with names in 
mathematical notation is standard for precisely the same reasons that it's 
a good idea for Python.

Best,
Stephan

(note: apologies for any redundant messages, I tried sending this message 
from the google groups mirror before I signed up, which didn't go out to 
the main listing list)

>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140703/50ad555c/attachment.html>