On Sun, Oct 19, 2014 at 6:43 AM, Nathaniel Smith <njs@pobox.com> wrote:

I feel strongly that we should come up with a syntax that is

unambiguous even *without* looking at the gufunc signature. It's easy
for the computer to disambiguate stuff like this, but it'd be cruel to
ask people trying to skim through code to work out the signature and
then simulate the disambiguation algorithm in their head.

Since code speaks stronger than mere words, here is a notebook showing my disambiguation algorithm:

http://nbviewer.ipython.org/gist/shoyer/7740d32850084261d870

I don't think this is so cruel, but I agree that the logic is more complex than ideal:

"If the axis argument is a sequence with length equal to the number of variables with axis specifications in the gufunc signature, then each element is taken to specify the axis for each corresponding variable. Otherwise, if the gufunc has only one variable with a core dimension, the entire axis argument is taken to refer to only that variable."

Notice in my suggestion above there are two different kwargs, "axis" and "axes".

Ah, I missed that. That's actually pretty elegant, so +1 from me. My only ask then would be that we allow for "axis" to also be a sequence of integers, in which case they are also used to specify the axis for the single variable, e.g., axis=(1, 2) translates to axes=[(1, 2)]. This would allow for using the axis argument in the same way as it works on ufunc.reduce already. I don't think distinguishing cases for "integer" vs "tuple of integers" is too complex.