On Mar 18, 2014, at 1:02, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 18 Mar 2014 09:08, "Nathaniel Smith" <njs@pobox.com> wrote:
>
> On Fri, Mar 14, 2014 at 8:15 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
> > A few other miscellaneous comments:
> >
> > - nice work on the PEP Nathaniel!
>
> Thanks!
>
> > - as with others, "@" as the operator doesn't thrill me, but I also think it
> > crosses the threshold of "good enough given the constraints"
> > - the PEP should probably recommend adding an "operator.matmul" function, a
> > "PyObject_MatrixMultiply" C API and consider whether or not the new special
> > method should be given a C level type slot.
>
> operator.matmul and PyObject_MatrixMultiply are obvious enough, but
> I'm afraid I'm not too clear on the tradeoffs about adding a C level
> type slot, or even entirely sure what the alternative is. (I guess I
> just assumed that all special methods used C level type slots and
> there was nothing to think about.) Do you (or anyone) have any
> thoughts?

I suspect you're going to want one, as without it, the implementation method ends up in the class dict instead (the context management protocol works that way).

I suspect the design we will want is a new struct for Py_Matrix slots (akin to those for numbers, etc). The alternative would be to just add more "Number" slots, but that isn't really accurate.

Someone needs to work out how these changes will affect the numpy C API (the Py_Array dotfunc slot, the PyArray interface, etc.). Whoever is doing that--and the numpy C API users who are interested in it--will probably care more about how matmul fits into the python C API than anyone else does.

As for whether this is another numeric operation or a new kind of operation, I think that depends on how you intuitively interpret matrix operations, or rather which intuition numpy and similar libraries should be encouraging. The fact that the proposal suggests that >2d arrays should handle matmul by broadcasting it over the final 2d subarrays seems like it's treating it fundamentally as a numeric operation on (vectors and) matrices. On the other hand, I don't think anyone implementing a split-complex or quaternion library on top of numpy would want to use @ for multiplying their numbers, even if they used @ on the matrices as the implementation.