On Sat, May 2, 2015 at 1:51 PM, BartC <b...@freeuk.com> wrote: > On 02/05/2015 20:15, Mark Lawrence wrote: >> >> On 02/05/2015 19:34, BartC wrote: > > >>> OK, so it's the programmer's fault if as fundamental a concept as a >>> for-loop ranging over integers is implemented inefficiently. He has to >>> transform it into high-level terms, or has to reconstruct it somehow >>> using a while-loop and an incrementing loop index. > > >> I give up. > > > So do I, I think, if no-one is willing to admit that the original way of > implementing range() was a glaring mistake.
range() was and is a *convenience* function. In the real world, the vast majority of for loops are over arrays or other containers, not integers, and those that aren't are usually very small. In non-toy code, using a for loop to count to a billion is highly unusual. So yeah, for a programmer porting code to Python who needed to loop over an array, the correct approach would be to actually loop over the *array* in place of the indices of the array. I don't know why you make this out to be such a big deal; it's a simple conversion. Would it have been better if range() had been implemented as xrange() from the beginning? Sure, that would have been great. Except for one small detail: the iterator protocol didn't exist back then. That wasn't introduced until PEP 234 in Python 2.1, which means that the xrange() function wasn't even *possible* before then. I don't think anybody would claim that Python was perfect when it was first introduced (nor is it perfect now). Like all other software, it has improved over time as a result of iterative refinement. -- https://mail.python.org/mailman/listinfo/python-list
