PEP 303: Extend divmod() for Multiple Divisors

[Paul Rubin]

"John Roth" <johnroth at ameritech.net> writes:
> I want to object to this one strongly, on the basis that it is
> a special case of something that, if it's useful at all, should
> be generalized to include all of the operators.

Not a bad idea.  There's no reason for operator.plus(3,4,5) to
throw an exception instead of returning 12.

> Erik Mac Francis' comment about the APL encode operator
> sounds about right, although I'd much prefer that thinking
> go in the direction of functional languages.
 
> As far as the nuts and bolts go, the operand should be
> a sequence, not simply strung out as operands. There are
> several reasons for this, but the major one is consistency:
> if the result is a list, then the input operand should also be
> a list.

That makes no sense.  Imagine a function that returns the
factorization of a number, e.g. the factors of 30 are 2, 3, and 5. 
It's natural and obvious for factor(30) to return the list (3,4,5).
Why on earth should its argument be a list?