Instead of the compiler, could the _runtime_ be made smart enough to
recognize that 'range' is being invoked in a context where a list isn't
truly needed? Seems to me this use in 'for' is the only one worth
special-casing (I've never seen, e.g., someone write 'if i in range(n)',
or other non-for contexts where a list isn't needed).
> 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. ...
If this is the way to do it, I'd rather that range be left alone & a new
builtin introduced. Think of all the Sieve of Eratosthenes programs
you'll break otherwise <wink>.
Or perhaps range could return an object of this new non-storing type, and
that also magically transforms itself into a vanilla list if used in a
context that requires a genuine list (including, but not limited to, the
"copy" context mentioned by Dirk). In fact, I like this one best of all
-- users wouldn't need to know the non-storing type existed. It's
an implementation hack, as it should be <grin>.
> An alternative solution, used in ABC, would be to have an efficient
> alternative representation of list objects consisting of ranges.
Agreed that's overkill; not common enough in Python (outside of "for") to
justify slowing down all lists.
voting-for-a-dirty-hack-under-the-covers-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp