<br><br><div><span class="gmail_quote">On 8/24/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 8/24/06, Neal Norwitz <<a href="mailto:nnorwitz@gmail.com">nnorwitz@gmail.com</a>> wrote:<br>> I've been working on enhancing xrange and there are a bunch of issues<br>> to consider. I've got pretty much complete implementations in both C
<br>> and Python. Currently xrange is 2 objects: range and the iter.<br>> These only work on C longs. Here's what I propose:<br>><br>> 2.6:<br>> * Add deprecation warning if a float is passed to xrange (currently
<br>> silently truncates)<br>> * Allow int, long, float, or obj.__index__<br><br>float? I thought the first bullet says no float?</blockquote><div><br>No, the bullet says 'add warning' :) xrange() currently accepts floats, because it uses one of the integer getargs formats:
<br><br>>>> xrange(1.2, 2.5, 1.9999)<br>xrange(1, 2)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * Implement xrange in python
<br><br>Since xrange is used in performance critical apps that may be a bad<br>idea. Or maybe only if the args aren't all ints?</blockquote><div><br>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.
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> Caveats:<br>> * The generator version above doesn't support floats. We could
<br>> easily support floats with a different calculation that would be<br>> slightly more expensive, but not have accumulated error.<br><br>Is there a good use case for supporting float? The problem with floats<br>
is that even apart from accumulated error, it's still ambiguous. E.g.<br>will xrange(1.1, 1.9, 0.1) include the end point or not? That would<br>depend on the details of decimal-to-binary conversion.</blockquote><div><br>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.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * With a python implementation there is a little bit of bootstraping<br>> that is necessary to get the iter implemented in C into the xrange
<br>> object implemented in Python<br><br>Long-term, I'd rather see it implemented all in C. Short term, the<br>Python implementation is great to experiment.</blockquote><div><br>Why, other than performance? It's a lot simpler and much easier to get right in Python, which is quite good for maintenance, too.
<br></div><br></div>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!