<p dir="ltr"><br>
On 4 Jul 2015 7:25 am, "Terry Reedy" <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br>
><br>
> On 7/3/2015 7:23 AM, Nick Coghlan wrote:<br>
>><br>
>> On 3 July 2015 at 06:20, Pierre Quentel <<a href="mailto:pierre.quentel@gmail.com">pierre.quentel@gmail.com</a>> wrote:<br>
>>><br>
>>> @Steven, Mark<br>
>>> The definition of range() in Python docs says :<br>
>>><br>
>>> Python 2.7 : "This is a versatile function to create lists containing<br>
>>> arithmetic progressions. It is most often used in for loops."<br>
>>><br>
>>> Python 3.4 : "The range type represents an immutable sequence of numbers and<br>
>>> is commonly used for looping a specific number of times in for loops."<br>
>><br>
>><br>
>> Pierre, I *wrote* the Python 3 range docs.<br>
><br>
><br>
> I think deleting 'arithmetic' was a mistake.  Would you mind changing 'immutable sequence' to 'immutable arithmetic sequence'?</p>
<p dir="ltr">Sure, clarifications aren't a problem - getting "arithmetic progression" back in the docs somewhere will be useful to folks familiar with the mathematical terminology for how range works.</p>
<p dir="ltr">> Also, I think 'numbers' should be narrowed to 'integers' (or whatever is actually accepted).  The idea of allowing floats has been proposed at least once, probably more, and rejected.</p>
<p dir="ltr">Unfortunately, we don't have a great word for "implements __index__", as "integer" at least arguably implies specifically "int".</p>
<p dir="ltr">>> There isn't a "general idea" behind Python 3's range type, there's a<br>
>> precise, formal definition.<br>
><br>
><br>
> 'predictable finite increasing or decreasing arithmetic sequence of integers, efficiently implemented'</p>
<p dir="ltr">Ah, I like that.</p>
<p dir="ltr">> range() looks at the value of step to decide whether to raise or return. Something must look as the sign of step to decide whether stop is a max or min, and what comparison to use.  Since the sign is constant, this determination need only be done once, though I do not know where or when it is currently done.<br>
><br>
> Given that a function has neither a value nor sign, and each call can have not only a different value, but a different sign.  A step function is a very messy fit to an api with a stop parameter whose meaning depends on the sign of step. For many sequences, one would want an explicit max or min or both.</p>
<p dir="ltr">Yeah, I started trying to think of how to do this generically, and I think it would need to be considered in terms of upper and lower bounds, rather than a single stop value.</p>
<p dir="ltr">That is, there'd be 6 characterising values for a general purpose computed sequence:</p>
<p dir="ltr">* domain start<br>
* domain stop<br>
* domain step<br>
* range lower bound<br>
* range upper bound<br>
* item calculation</p>
<p dir="ltr">However, you fundamentally can't make len(obj) an O(1) operation in that model, since you don't know the output range without calling the function.</p>
<p dir="ltr">So the general purpose form could be an iterator like:</p>
<p dir="ltr">    def within_bounds(iterable, lower, upper):<br>
        for x in iterable:<br>
            if not lower <= x < upper:<br>
                break<br>
            yield x</p>
<p dir="ltr">Positive & negative infinity would likely suffice as defaults for the lower & upper bounds.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>