[Python-Dev] best practices stdlib: purging xrange

[O.R.Senthil Kumaran]

* James Y Knight <foom at fuhm.net> [2007-05-08 11:18:44]:

> On May 8, 2007, at 8:49 AM, Armin Rigo wrote:
> > On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
> >> I'd like to suggest that we remove all (or nearly all) uses of
> >> xrange from the stdlib. A quick scan shows that most of the usage
> >> of it is unnecessary. With it going away in 3.0, and it being
> >> informally deprecated anyway, it seems like a good thing to go away
> >> where possible.
> >
> > I personally think that replacing these with range() is a clean-up,  
> > but
> > I also know that not everybody agrees to that.  So: should we, or  
> > should
> > we not, replace xrange() with range() as a matter of clean-up when the
> > difference between the two is really completely irrelevant?
> 
> But doesn't doing this now this make the conversion to Py3 *harder*?  
> If 2to3 is going to rewrite xrange() as range(), and range() to list 
> (range()), then moving towards xrange where possible would actually  
> be preferable, wouldn't it? Or is there no plan to run 2to3 on the  
> stdlib?

Looking at xrange() and range() definitions and from this discussion, it seems
to me that xrange() to be preferable over range(). Its common that most of the
code have range() because its simple use in iteration, but if same
functionality is provided with xrange as an object. And doing
:s/xrange/range/g would make sense also. ( Am I right in understanding this?)

Why range or xrange and why not xrange or range?
Or is this discussion about why having two functions with similar (or rather
same) functionality, and lets move to one and in which case either of them is
fine.

-- 
O.R.Senthil Kumaran