Re: Baby X is bor nagain

On 21/06/2024 00:40, bart wrote:

During the last 20 or more years, Python implementations have gotten more and more efficient. So if there is a difference between range and xrange, there are techniques that can be used to minimise it.

Yes.  Like most languages (except assembly, Forth, and perhaps a few other very low-level languages) Python is defined in terms of its effects, not specific implementations of its features.  The effect of generating a list of consecutive integers then iterating over it, and of generating a C for style loop, are the same - but obviously the run-time efficiency will typically be very different.
Python is not a language with much optimisation in itself - but the compiler (byte-compiler) has got more sophisticated over time.  Common use-cases of range where the list nature of the range is not important, have been improved - modern Python does not generate a list for ranges unless they are actually necessary.
Conceptually, having ranges as a list is very nice.  It is a design choice geared towards ease of use, consistency and functionality, rather than ease of efficient implementation.  Like functional programming languages, it's a design that appeals to people thinking mathematically or with high-level concepts in mind, but it will seem alien and inefficient to people thinking from the low level up or considering implementation details.
Your programming experience has mainly been through assembly, low-level languages, and implementation of your own fairly low-level languages.  I expect that whenever you see code in any language, part of your mind is automatically trying to think of how you could implement that in a code generator.  So when you see something like Python's "range" expression, you immediately see the obvious implementation, and that this is clearly a highly inefficient way to get a simple for-loop.
I too have a background in assembly - even lower, in fact, since I work with electronics and am also familiar with logic design and the basic principles of processor design.  But I also have a background in mathematics, and as well as assembly and C, I have worked with functional programming languages and other high-level languages.  To me, there is nothing wrong with using recursive functions over infinite lists as a way of making a loop - /if/ the language supports it reasonably efficiently.  And there is nothing wrong with a language that is 1000 times slower to run but 10 times faster to code.

 But if should never have been done that crazy way in the first place.
 However if I compare range to xrange now on Py2 using such loops as your examples, then xrange is about twice as fast. But range on Py3 is in-between. Basically I've no idea what's going on inside it these days.

xrange always gives you a structure that is a kind of iterator or generator - it holds a start value, end value, step value and current value.  It is not a list, and does not have the same types of methods as a list.  For example, you can't modify it.
In Python3, range() actually returns an range object, which is basically a rename of the Python2 xrange object.  To get the old behaviour of range() as a list, you now need to write "list(range(100))".
A major point, however, is that for the most part, you don't need to know what is going on inside it.  I know you like to understand these things (I do too), and it's hard to turn off the curiosity instincts. But at least understand that for the vast majority of other users, the underlying details don't matter.  Their Python "for" loops are faster than they used to be, and that's nice - why bother about the hidden details when there are other things to occupy one's time and brainpower?