[Python-Dev] PEP 303: Extend divmod() for Multiple Divisors
Tim Peters
tim.one@comcast.net
Wed, 01 Jan 2003 12:35:34 -0500
[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