PEP 260: simplify xrange()

[Michael Robin]

I second this sentiment - if xrange is going to be used idiomatically
for looping only (well, in any case) I would like to see the sequence
itself acceptable as a parameter. xrange(seq) seems perfectly clear
(and in single-parameter form also doesn't depend on a 0-based start
index as len(seq) does).

Side-discussion:

Of course, you could just call (or alias) the new xrange
"indices(...)" (and/or "indexes" :) ) to make evident its true colors,
and mark xrange for complete removal in a later version, while
supplying a python-coded version to keep code working - but I guess
xrange is too embedded in the pythoner's psyche... (The name "range"
is especially confusing in a way, considering you pass in what's
normally considered the mapping's "range" and it's returning the
"domain".)

It sounds like the PEP won't kill much code, but restricting xrange as
proposed reduces the symmetry in the laguage which is one of its good
points. I wonder = using the non-use metric, there are probably other
things that can be removed. (How many people use "if dict1 < dict2
..."?) It seems like lot's of stuff could be removed from the core,
and the outliers could be put in (C or python-coded) modules that
could be included to "round-out" a particular class of objects, so if
you really wanted to compare dictionaries you could include (import)
this support. (When we can subclass types, this should be easier.)

m


"Delaney, Timothy" <tdelaney at avaya.com> wrote in message news:<mailman.993602265.26300.python-list at python.org>...
> > Here's another sweet and short PEP.  What do folks think?  Is
> > xrange()'s complexity really worth having?
> > 
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> > 
> > PEP: 260
> > Title: Simplify xrange()
> > Version: $Revision: 1.1 $
> > Author: guido at python.org (Guido van Rossum)
> > Status: Draft
> > Type: Standards Track
> > Python-Version: 2.2
> > Created: 26-Jun-2001
> > Post-History: 26-Jun-2001
> > 
> > Abstract
> > 
> >     This PEP proposes to strip the xrange() object from some rarely
> >     used behavior like x[i:j] and x*n.
> > 
> > 
> > Problem
> > 
> >     The xrange() function has one idiomatic use:
> > 
> >         for i in xrange(...): ...
> 
> If this is to be done, I would also propose that xrange() and range() be
> changed to allow passing in a straight-out sequence such as in the following
> code in order to get rid of the need for range(len(seq)):
> 
> import __builtin__
> 
> def range (start, stop=None, step=1, range=range):
>     """"""
> 
>     start2 = start
>     stop2 = stop
> 
>     if stop is None:
>         stop2 = start
>         start2 = 0
> 
>     try:
>         return range(start2, stop2, step)
>     except TypeError:
>         assert stop is None
>         return range(len(start))
> 
> def xrange (start, stop=None, step=1, xrange=xrange):
>     """"""
> 
>     start2 = start
>     stop2 = stop
> 
>     if stop is None:
>         stop2 = start
>         start2 = 0
> 
>     try:
>         return xrange(start2, stop2, step)
>     except TypeError:
>         assert stop is None
>         return xrange(len(start))
> 
> a = [5, 'a', 'Hello, world!']
> b = range(a)
> c = xrange(4, 6)
> d = xrange(b)
> e = range(c)
> 
> print a
> print b
> print c
> print d
> print e
> print range(d, 2)
> 
> Tim Delaney