PEP 303: Extend divmod() for Multiple Divisors
phr-n2002b at NOSPAMnightsong.com
Wed Jan 1 15:17:55 CET 2003
"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?
More information about the Python-list