[Python-Dev] Re: More int/long integration issues
David Abrahams
dave@boost-consulting.com
Fri, 21 Mar 2003 09:43:36 -0500
Fri, 21 Mar 2003 09:43:36 -0500
- Previous message: [Python-Dev] Re: More int/long integration issues
- Next message: [Python-Dev] Re: More int/long integration issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum <guido@python.org> writes: >> Guido van Rossum <guido@python.org> writes: >> >> > The bytecode compiler should be clever enough to see that you're >> > writing >> > >> > for i in range(...): ... >> > >> > and that there's no definition of range other than the built-in one >> > (this requires a subtle change of language rules); it can then >> > substitute an internal equivalent to xrange(). >> >> Ouch! What happens to: >> >> def foo(seq): >> for x in seq: >> ... >> >> foo(xrange(small, really_big)) >> >> if xrange dies?? > > Good point. I guess xrange() can't die until range() becomes an > iterator (which can't be before Python 3.0). > > Hm, maybe range() shouldn't be an iterator but an interator > generator. No time to explain; see the discussion about restartable > iterators. I think what you mean is fairly obvious. list et al. are iterator generators, right? It's just a thing with an __iter__ function which produces an iterator? If so, I tend to agree that's the right behavior for range(). range(x,y,z) should be an immutable object. -- Dave Abrahams Boost Consulting www.boost-consulting.com
- Previous message: [Python-Dev] Re: More int/long integration issues
- Next message: [Python-Dev] Re: More int/long integration issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]