[Python-Dev] PEP 303: Extend divmod() for Multiple Divisors

[Tim Peters]

[Christian Tismer]
>> Therefore, I consider divmod a waste of code and
>> a function to be deprecated ASAP (and since years).

[Guido]
> Maybe it wasn't such a good idea.

You can remove divmod() when I'm dead.  Before then, it stays.  I'm sure all
will agree that's a reasonable compromise.

> ...
> But what about long division, where divmod can (in extreme cases)
> really save time by doing the division only once?

On my box, divmod(x, y) is already 40% faster than "x//y; x%y" when x is a
63-bit int and y is 137354.  In the hundreds of places I've used it in
programs slinging multi-thousand bit integers, it's essentially twice as
fast.

But I don't care so much about that as that divmod() is the right conceptual
spelling for the operation it performs.

If we have to drop a builtin, I never liked reduce <wink>, although Jeremy
pointed out that its most common use case no longer requires writing a
lambda, or importing operator.add:

>>> reduce(int.__add__, range(11))
55
>>>

This is a little suprising if you toss a mix of types into it, though, since
int.__add__ isn't operator.add:

>>> reduce(int.__add__, [1, 2, 3.0])
NotImplemented
>>>

OTOH,

>>> reduce(float.__add__, [1, 2, 3.0])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: descriptor '__add__' requires a 'float' object but received a
'int'
>>>

It's a good way to reverse-engineer the internals <wink>.

"on-topic"-is-my-middle-name-ly y'rs  - tim