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/2001-June/015580.html below:

[Python-Dev] xrange vs generators

[Python-Dev] xrange vs generatorsGuido van Rossum guido@digicool.com
Mon, 25 Jun 2001 12:11:10 -0400
>  [ xrange can't be changed into a generator ]
> 
> > This is too bad; I really wish that xrange() could die or be limited
> > entirely to for loops.  I wonder if we could put warnings on xrange()
> > uses beyond the most basic...?
> 
> Why do we want to do this ? xrange() is still exactly what it was: an object
> that pretends to be a list of integers. Besides being useful for those who
> work a lot with ranges, it's a wondeful example on what you can do with
> Python (even if it isn't actually written in Python :-)

There is exactly *one* idiomatic use of xrange():

  for i in xrange(...): ...

All other operations supported by the xrange object are very rarely
used, and historically their implementation has had obvious bugs that
no-one noticed for years.

> I see less reason to deprecate xrange than to deprecate the gopherlib,
> wave/aifc/audiodev, mhlib, netrc and/or robotparser modules. 

Those are useful application-area libraries for some folks.

The idiomatic xrange() object is useful too.

But the advanced features of xrange() are an example of code bloat.

--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