[Python-Dev] Infix operators (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Jul 25 07:27:06 CEST 2008

Scott Dial wrote:

I would argue that Python contains a "array of sometype" 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

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

More information about the Python-Dev mailing list