[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