[Python-Dev] request for minor enhancement / linear algebra

[Martin v. Loewis]

> I got there by working backwards to make things consistent.  I want
> overloadable '__min__' and 'min=', and everything else that has
> these forms is binary infix (I think).

If min was overloadable, it would fall in the same category as

cmp, divmod, getattr, hasattr, hash, hex, int, len, long, oct, pow,
repr, setattr, str

the category being "overloadable builtins". Of those, cmp, divmod,
getattr, hasattr, pow and setattr take more than one argument.  divmod
and pow are truly binary in the sense that both __foo__ and __rfoo__
are tried.

So if min was overloadable, there would be no need for it being infix;
it should attempt both __min__ and __rmin__, though. Actually, it
shouldn't - instead, it should invoke __min__ on every argument.

> '+', '*', and the bitwise operators are equally variadic --- is
> confusion avoided by using punctuation for the infix binary form,
> and a named function for the general form?

An infix operator, by nature, cannot be variadic. 1+2+3 is not a
single operation returning 6, but two operation invocations. Likewise,

>>> import operator
>>> operator.add(1,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: function requires exactly 2 arguments; 3 given

Unlike that, min(1,2,3) *is* an atomic operation. If it was
overloadable, I would *not* expect that first __min__(1,2) is
computed, and then __min__(1,3). Instead, I'd expect it to be done as
a whole.

Now, the question is: if the first argument does not provide __min__,
how exactly should __min__ be invoked on the other arguments? One
solution would be that min(a,b,c) does

a.__min__([a,b,c])
b.__min__([a,b,c])
c.__min__([a,b,c])

Regards,
Martin