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/