Range Operation pre-PEP

[Carlos Ribeiro]

At 16:17 08/05/01 +0200, Thomas Wouters wrote:
> >         >>> for i in 1 .. 5:
> >         ...     print i
> >         1
> >         2
> >         3
> >         4
> >         5
>
>I like, though the endpoint is debatable. Maybe Greg W. wants to do some
>usage testing ? :)

I think the syntax is clear enough to avoid discussions like 
does-it-start-from-one-or-zero? Let the a..b syntax delimit the range 
*including* both the minimum and maximum values. BTW it's pretty close to 
the range syntax in other languages (such as Pascal, for enumerated 
constants and sets).

> >     Or in extended form to specify a step:
>
> >         >>> for i in (1, 3) .. 5:
> >         ...     print i
> >         1
> >         3
> >         5
>
>I don't like this. If anything, it should be the other way 'round
>("1 .. (5, 3)") but even better would be something more obvious, such as
>
>(1 .. 5) % 3

This one is a little bit harder. Where did you take the 3 on the example 
above? I could not understand the logic of '(1 .. 5) % 3'. I think that the 
range operator should specify the step; something like '1 .. 5 % 2' is 
clearer in my opinion. The use of '%' as 'step' operator is highly 
debatable, though. Why not use any of the characters [!@#$&] ? <wink>

(if we keep going this way '%' is going to be the most overloaded operator 
in the history of programming languages :-)

> >     The new operation ".." generates xrange object
> >     on by following rule:
>
>I'd suggest it create an Iterator rather than an xrange object. Iterators
>are new in the CVS tree, and will be in Python 2.2. Very neat things ;)

Agreed. In fact, xrange could be internally substituted by iterators.

As for other types of range constructors: in Pascal, you can use the syntax 
above to construct ranges for enumerated types or sets. The catch is that 
only scalar types can be used. This makes sense in Pascal, because the same 
syntax is also used to specify sets. In Python, similarly, the same syntax 
could be used (in the future) to implement set libraries. OTOH, ranges 
built with floats may experience problems caused by the limited precision, 
so that's a good reason to avoid it. Fixed point decimals don't suffer from 
the same problems, though, and are a better candidate.


Carlos Ribeiro