Guido van Rossum wrote: ...
mm, ss = divmod(ss, 60)
easier to read than
mm, ss = ss//60, ss%60
Before I retract completely, I have a small addition.
mm = ss//60; ss %= 60
is very readable to me, very efficient, and doesn't use extra tuples. It is also 2 characters shorter than the divmod version (both with the usual spacing, of course). On the other hand, divmod clearly says what is going to happen, and in fact it is a higher level approach.
On dropping features, I came to this in the morning:
You said you might optimize certain builtins by the compiler, instead of removing divmod.
How about this: If divmod is supported by the compiler, there isn't any reason to keep it as a compiled C module. Instead, divmod could be a piece of Python code, which is injected into builtins somewhere at startup time. Since he compiler supports it, it just needs to be there at all, but does not need to waste space in the Python executable.
I'm not saying this just to fight divmod out of the language. This is ridiculous. But in the long term, there might be quite a lot of redundancy introduced by enhanced versions of the compiler. Instead of letting the code grow on and on, I'd like to propose some shrinking attempt like in this case. If the compiler eats 95 percent of calls to some code already, I believe it makes sense to replace that piece of code by Python code and drop the C version.
The smaller the C code base, the better for Python. Less static code also improves the effect of compilers like Psyco. Let's make a smaller and better kernel. Get rid of ballast and have less code to maintain.
This is a real wish and *no* Silvester joke :-)
cheers - chris