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

Christian Tismer tismer@tismer.com
Wed, 01 Jan 2003 03:44:04 +0100


Guido van Rossum wrote:
> On the one hand I find this a nice backwards-compatible extension of
> divmod().  On the other hand I've coded this use case with separate
> divmod() calls and never had any trouble getting it right.  So I think
> this doesn't address a real need, and it conflicts with the need to
> avoid unnecessary growth of the language.  Explaining it (especially
> why it works backward) takes some effort, and I don't want to do that
> to all the book authors etc.

I totally agree. This nice extension to divmod() turns
the function into something more polynomial algebra
related, and divmod is no longer the proper name of
the function. Also, the specialized use of it makes
it more suitable to be put into a general algebra
module for Python, for sure not into the builtins.

Having that said, let's have a closer look at divmod.

It appears in 36 .py files out of about 1500 .py files
in the Python 2.2 source distribution. This is little
more than 2 percent.
The effort to correctly remember the order of the
arguments and the results tuple does not suffice
to justify the existance of this function at all.
Furthermore, divmod does not provide any
functionality that isn't easily obtained by a
simple div and mod.

Finally, and for me this is the killer argument
for divmod:
The standard use of divmod is splitting numbers
over small integer bases. I can only see an advantage
for divisions which come at high computational
cost, which is factorizing polyomials or large numbers.
But for the majority of applications, a quick time
measurement of the function call overhead against
doing an inline div and mod, I found that divmod
compared to / and % is at least 50 percent *slower*
to compute, due to the fact that a function call,
followed by building and unpacking a result tuple
is more expensive than the optimized interpreter
code. The real computation is neglectible for
small numbers, compared to the overhead of the engine.

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

Save brain cells, save computation time, and save
paper and ink of the book writers by dropping divmod!

Vice versa, if at all, I suggest a built in /% operator
as a faster equivalen to single / and %, but I believe
this code can be used more efficiently.
divmod should be a special case of an algebraic
extension module and removed from the builtins.

Python has got a lot of extensions, modelled towards
more user-friendlyness. I do think that this goal
can be achieved not only by extending, but also
by deprecating functions which have little or no
benefits over built-in operators. The existence
of divmod gives the wrong feeling of optimizing
one's code, which is a lie to the user.
divmod does not save computation time, does not
reduce programming time, does not simplify programs,
eats paper and code space. divmod is also even not
found in common compiled languages any longer.
Even there, division isn't expensive enough to justify
yet another function to remember and to implement.

Please drop divmod. We will not miss it.

from-__past__-import-divmod - ly y'rs -- chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/