number ranges

Antoon Pardon apardon at forel.vub.ac.be
Wed Feb 22 04:07:12 EST 2006


Op 2006-02-21, Tim Hochberg schreef <tim.hochberg at ieee.org>:
>
> [Lots of proposals snipped]
>
> 90% of my gripes with range disappeared with the addition of enumerate. 
> However, if there's going to be another round of range literal proposals 
> I might as well throw out what seems (to me anyway) like the only 
> halfway obvious choice in the context of Python.
>
> 1. a:b:c is equivalent to slice(a,b,c) with the usual rules that missing 
> values are mapped to None: Parentheses would be required where this 
> construct would otherwise be ambiguous.

I think this would be the way to go if want a chance of having it in
python 2.x.

However I would think that a Bottom and Top value (respectively being
smaller and larger than all other objects) would be better suited as
default values for python 3000

> 2. slice(a,b,c) grows an __iter__ method that returns a generator that 
> produces an appropriate sequence of integers. This is easy to define for 
> positive steps, but tricky for negative steps (more on that in a second).
>
> Thus:
>
> for i in (1::2): print i,
>=> 1 3 5 ...
>
> and
>
> for i in (:10:3): print i,
>=> 0 3 6 9
>
>
> The tricky part is deciding what to with negative steps when the start 
> is undefined. It's tempting to use 0 as the start, but I think -1 is 
> actually better if slightly odd. The reason is that I think the 
> following invariant should hold.

In python 2.x I would either throw an exception or continuely return
None if the start value isn't given.

For python 3000 I would continously return Bottom or Top if the start
value wasn't given, depending on step being positive or negative.

-- 
Antoon Pardon



More information about the Python-list mailing list