On 8/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
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)
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.
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.
Why, other than performance? It's a lot simpler and much easier to get right in Python, which is quite good for maintenance, too.
-- On 8/24/06, Neal Norwitz <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
