Home Original page

PEP 303: Extend divmod() for Multiple Divisors

Thomas Bellman bellman+pep-divmod at lysator.liu.se
Thu Jan 2 17:25:16 EST 2003 
"John Roth" <johnroth at ameritech.net> wrote:

> 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.

Yes, I have had thoughts about that too.  However, divmod differs
from the other operators in one important aspect: it returns
*two* values.  The other operators can easily be chained by using
reduce(); divmod can't (easily).

And there is actually another aspect that is different: divmod
isn't an operator, but a function. :-)

> I don't find the use cases very compelling. Sure, they exist,
> but how many of us actually use chained division for those
> conversions in every day life rather than use a library
> module?

I do. :-)  And more importantly, I think that even library code
should be allowed to read well.

> And how many of those uses are actually
> the performance bottleneck in the system?

The motivation for this extension is clarity, not speed.

> 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.

If I was suggesting a new function, I would probably agree with
you.  However, I'm proposing to extend an existing function, and
the API for a single divisor is already set in stone.  I think it
would be a very bad idea for divmod to change its behaviour based
on whether the second argument was a sequence or not.


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"You cannot achieve the impossible without   !  bellman @ lysator.liu.se
 attempting the absurd."                     !  Make Love -- Nicht Wahr!
More information about the Python-list mailing list