> It occurs to me that the compiler could probably generate optimized code
> in the case where it sees the statement
>
> for <ident> in range(<expression>):
>
> The list result of range() never really needs to exist, in this case, no?
Well the compiler isn't very good at recognizing calls to built-in
functions ('range' could be a local identifier with a different
meaning). But someone else proposed that range() return a new object
type that behaves like a sequence but doesn't store all its elements,
just returns the one you ask for.
I am beginning to like this solution. It would not be 100 percent
compatible, since uses of range() in other contexts would work
differently or not at all (e.g. you can't initialize a list with a
range and then remove items from it) but those uses would be a far
minority.
An alternative solution, used in ABC, would be to have an efficient
alternative representation of list objects consisting of ranges.
Unfortunately this would complicate the implementation of all list
operations, so I'm not in favor of it, even though it would be
marginally cleaner for the user.
Any other opinions?
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>