[pypy-dev] XRange Object [Fixed Patch]

[holger krekel]

Hey Moshe!

[Moshe Zadka Tue, Jul 08, 2003 at 08:58:20AM -0000]
> OK, I fixed the problem of not registering in the builtins, and now
> 
> moshez at green:~/devel/pypy/src/pypy$ python2.2 interpreter/py.py  -S
> Python 2.2.2 (#1, Nov 21 2002, 08:18:14)
> [GCC 2.95.4 20011002 (Debian prerelease)] in pypy
> PyPyConsole / StdObjSpace
> >>> for i in xrange(0,1,1):
> ...     print i
> ...
> 0
> 
> [Though, this being my first playing around with PyPy, I must say I
> was a bit taken aback by just how slow it is :)]

The slower it is now all the more faster it gets later :-)

> Diff still vs. 1116
> 
> Thanks and sorry for the slight spamming,

thanks you for the patch.  But i think that "xrange" should really
be a builtin rather than a first-class type on stdobjspace.  

Thanks to the last sprint we now have generators so this is rather
easy to do (in module/builtin_app.py).  Btw, is there a reason we
don't compile with generators turned on in "interpreter/appfile.py"? 

I just did a quick try at copy/modify of range into "xrange" and it
seems to work fine.  Now, i would like to check *that* in but i am
not sure about the "append"-problem.  The implementer of "range"
took great care to not use "list.append" but to compute the size 
of the list before hand.  But filter/map/zip.. use list.append anyway
and i think we should just make "range" use "xrange" the simple way

    arr = []
    for i in xrange(x,y,step):
        arr.append(i)
    return arr

or 

    arr = []
    map(arr.append, xrange(x, y, step)
    return arr

IOW, i think we should allow list.append for the time beeing because
it is neccessary to work anyway e.g. for map applied to an
iterator/generator.  

cheers,

    holger