[Python-Dev] Infix operators

[Greg Ewing]

Scott Dial wrote:

> I would argue that Python contains a "array of some_type" data type. 
> That sum() performs a left-fold of __add__ on the array is completely 
> independent of them being numbers.

That's not strictly true -- it explicitly refuses to operate
on strings (or at least it did last time I heard). Guido has
said that he *intends* it to only be used for numbers, even
if it happens to accidentally do something with other types.

However, as I envisage it, the @ operator wouldn't be
restricted to numbers either -- it would do whatever the
* and + operations do on the elements.

 > sum() is not an operator, it is a builtin; the
> suggestion was for there to be an operator, not a builtin.

That's true, and it means that the built-in implementation
wouldn't have as wide applicability as the sum() function,
since it would be restricted to lists and tuples (and
perhaps array.array instances). But I don't think that's a
fatal flaw -- if you create your own sequence type, you
have to take steps if you want to be able e.g. to use +
to concatenate them, and nobody complains about that.

> If you want 
> to suggest there be a mmul() builtin, then perhaps there is a viable 
> answer there

No, that's not a viable answer to people who want a matrix
multiplication operator. They want an operator because a
function is nowhere near concise enough. Telling these
people they have to use a function to multiply matrices
is like telling them they have to use a function to
multiply numbers.

> What is "a plausible representation of a matrix"? Is it a list of lists?

That's one. A tuple of tuples would be another.

> Row-major (m[1][2]) or column-major (m[2][1])?

Pick one and stick to it. Probably row-major, since it's
what the numpy matrixmultiply function uses.

> Is it a dictionary of tuple'd indices (m[1,2])?

I think dictionaries would have to be excluded, because
there's no easy way of finding out the dimensions, it's
not obvious what to do about missing elements, etc.

> Also, You went on to talk about wanting to using numpy.array.

Yes -- what's wrong with that?

> How does this not make it clear that there is not a case of TOOWTDI?

I think there *is* one obvious way of representing a matrix,
or any 2D array, using built-in Python types, or rather two
ways -- a list of lists if you want mutability, or a tuple
of tuples if you want immutability.

-- 
Greg