Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Fri, 21 Jun 2024 10:02:49 +0200
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <v53c39$320dd$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <20240617002924.597@kylheku.com>
 <v4pddb$m5th$1@dont-email.me> <20240618115650.00006e3f@yahoo.com>
 <v4rv0o$1b7h1$1@dont-email.me> <20240618184026.000046e1@yahoo.com>
 <v4sd75$1ed31$1@dont-email.me> <877celzx14.fsf@nosuchdomain.example.com>
 <v4u85k$1t2pu$2@dont-email.me> <v4ucmn$1u14i$1@dont-email.me>
 <v4v2br$22c0m$1@dont-email.me> <v4v5nu$230rh$2@dont-email.me>
 <v4vfrn$24rv6$1@dont-email.me> <v4vjs4$25vmc$1@dont-email.me>
 <v510k3$2hhli$1@dont-email.me> <v51bb8$2jhji$1@dont-email.me>
 <v51gjh$2k86b$1@dont-email.me> <v51n3h$2lmvr$1@dont-email.me>
 <v522mm$2nkhu$1@dont-email.me> <v52b4i$2pfs4$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 21 Jun 2024 10:02:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="017bd53d5809bfe07afbcdbc63488ddf";
	logging-data="3211693"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+FAQIGvwcmmjqZTRiQP5rzf4BPjgePGwA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:22SB2lHR8u6Rr3+JuvnFjI7AIbg=
In-Reply-To: <v52b4i$2pfs4$1@dont-email.me>
Content-Language: en-GB
Bytes: 5861

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?