[Python-Dev] xrange accepting non-ints

[Thomas Wouters]

On 8/24/06, Guido van Rossum <guido at python.org> wrote:
>
> On 8/24/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> > I've been working on enhancing xrange and there are a bunch of issues
> > to consider.  I've got pretty much complete implementations in both C
> > and Python.  Currently xrange is 2 objects:  range and the iter.
> > These only work on C longs.  Here's what I propose:
> >
> > 2.6:
> >  * Add deprecation warning if a float is passed to xrange (currently
> > silently truncates)
> >  * Allow int, long, float, or obj.__index__
>
> float? I thought the first bullet says no float?


No, the bullet says 'add warning' :) xrange() currently accepts floats,
because it uses one of the integer getargs formats:

>>> xrange(1.2, 2.5, 1.9999)
xrange(1, 2)

>  * Implement xrange in python
>
> Since xrange is used in performance critical apps that may be a bad
> idea. Or maybe only if the args aren't all ints?


Is the cost of *calling* xrange() really a big issue? I don't think Neal
measured this, but he could. I'd imagine performance-critical apps call
xrange() once, then use that to iterate.

>
> > Caveats:
> >  * The generator version above doesn't support floats.  We could
> > easily support floats with a  different calculation that would be
> > slightly more expensive, but not have accumulated error.
>
> Is there a good use case for supporting float? The problem with floats
> is that even apart from accumulated error, it's still ambiguous. E.g.
> will xrange(1.1, 1.9, 0.1) include the end point or not? That would
> depend on the details of decimal-to-binary conversion.


Supporting floats is definately problematic. It would be nice if xrange()
supported arbitrary numeric types, though, like decimals. That would quench
the thirst people seem to have for float-ish xranges.


> >  * With a python implementation there is a little bit of bootstraping
> > that is necessary to get the iter implemented in C into the xrange
> > object implemented in Python
>
> Long-term, I'd rather see it implemented all in C. Short term, the
> Python implementation is great to experiment.


Why, other than performance? It's a lot simpler and much easier to get right
in Python, which is quite good for maintenance, too.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060824/eca0c56f/attachment-0001.htm