A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-April/034516.html below:

[Python-Dev] Re: More int/long integration issues

[Python-Dev] Re: More int/long integration issuesGuido van Rossum guido@python.org
Fri, 11 Apr 2003 16:32:51 -0400
> On Fri, 2003-03-21 at 06:55, Guido van Rossum wrote:
> 
> > > > Hm, maybe range() shouldn't be an iterator but an interator
> > > > generator.  No time to explain; see the discussion about
> > > > restartable iterators.

[Chad Netzer]
> Hmmm. Now that've uploaded my patch extending range() to longs,

(And now that I've checked it in. :-)

> I'd like to work on this.  I've already written a C range() iterator
> (incorporating PyLongs), and it would be very nice to have it
> automatically be a lazy range() when used in a loop.
> 
> In any case, assuming you are quite busy, but would consider this for
> the 2.4 timeframe, I will do some work on it. If it is already being
> covered, I'll gladly stay away from it. :)

range() can't be changed from returning a list until at least Python
3.0.

xrange() already is an iterator well.  So I'm not sure there's much to
do, especially since I think making xrange() support large longs goes
against the design goal for xrange(), which is to be a lightweight
alternative for range() when speed is important.

--Guido van Rossum (home page: http://www.python.org/~guido/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4