BartC, 06.09.2010 12:38:
why doesn't Python 3 just accept 'xrange' as a synonym for 'range'?
Because Python 3 deliberately breaks backwards compatibility in order to clean up the language.
These are just some simple tests on my particular machine and implementations, but they bring up some points: (1) Loop unrolling does seem to have a benefit, when the loop body is small.
Nobody said otherwise. However, "small" is a pretty weak characterisation here. And don't expect CPython to do it for you, because doing it automatically requires the ability to see that there are no side effects. It's a lot more costly to assure that than what you actually gain with the optimisation. As your example shows, doing this optimisation manually is pretty straight forward, so there isn't really a need to let the runtime do it for you.
(2) Integer arithmetic seems to go straight from 32-bits to long integers; why not use 64-bits before needing long integers?
You are making assumptions based on Python 2, I guess. Try Python 3.1 or later instead, where the int and long types are unified. Also, the implementation is a bit more complex than you appear to be thinking. Don't forget that it has received serious benchmarking based optimisations.
(3) Since the loop variable is never used, why not have a special loop statement that repeats code so many times?
Because special cases are not special enough to break the rules. As others have stated before, you can use itertools to reduce that part of the looping overhead, if it really hurts your concrete code. There also were lots of examples in this thread on different looping solutions and their performance differences. Any of them may fit your needs in a given situation.
This can be very fast, since the loop counter need not be a Python object
It still has to count, though. Stefan -- http://mail.python.org/mailman/listinfo/python-list
