PEP 303: Extend divmod() for Multiple Divisors

[John Roth]

"Paul Rubin" <phr-n2002b at NOSPAMnightsong.com> wrote in message
news:7xwulpuf70.fsf at ruckus.brouhaha.com...
> "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?

Ah, but that's a different situation. For a factorization, you've
got a single number going in. For the suggested usage, you've
got a 1 to 1 correspondance between the input numbers and
the output numbers: each divisor produces one element of the
output list (with a possible final remainder.)

I wouldn't expect a factor function to have a list input.

John Roth
>