On Sun, Mar 23, 2014 at 11:40:10AM +0100, Sturla Molden wrote:
On 15/03/14 01:09, Antoine Pitrou wrote:
Really? That should be up to the third-party library implementing the @ operator for its types, not to the language itself: Python _suggests_ an use case for @, it doesn't mandate it (especially as there's no appropriate data type in the stdlib).
array.array is an appropriate type for supporting @ for matrix multiplication.
No it isn't. The PEP even discusses it: [quote] array objects cannot represent multidimensional data at all, which makes ``__matmul__`` much less useful. Second, providing a quality implementation of matrix multiplication is highly non-trivial. Naive nested loop implementations are very slow and providing one in CPython would just create a trap for users. But the alternative -- providing a modern, competitive matrix multiply -- would require that CPython link to a BLAS library, which brings a set of new complications. In particular, several popular BLAS libraries (including the one that ships by default on OS X) currently break the use of ``multiprocessing`` [#blas-fork]_. And finally, we'd have to add quite a bit beyond ``__matmul__`` before ``memoryview`` or ``array.array`` would be useful for numeric work -- like elementwise versions of the other arithmetic operators, just to start. [end quote] I don't think we should be looking for additional use-cases for @. Either the PEP stands on its own, and @ is approved for matrix multiplication (and possibly @@ for exponentiation), or it isn't. If the PEP is accepted -- and I think it should be -- then people will invent new uses for @. Or they won't. Either way, it doesn't matter. -- Steven