number ranges (was Re: Matlab page on scipy wiki)

[Colin J. Williams]

Colin J. Williams wrote:
> Bryan Cole wrote:
> 
>>>       
>>> First, I think the range() function in python is ugly to begin with.
>>> Why can't python just support range notation directly like 'for a in
>>> 0:10'.  Or with 0..10 or 0...10 syntax.  That seems to make a lot more
>>> sense to me than having to call a named function.   Anyway, that's a
>>> python pet peeve, and python's probably not going to change something
>>> so fundamental...   
>>
>>
>> There was a python PEP on this. It got rejected as having too many
>> 'issues'. Pity, in my view.
>>
>> see http://www.python.org/peps/pep-0204.html
>>
>> BC
>>  
>>
> This decision appears to have been made nearly six years ago.  It would
> be a good idea to revisit the decision, particularly since the reasons
> for rejection are not clearly spelled out.
> 
> The conditional expression (PEP 308) was rejected but is currently being
> implemented in Python version 2.5.  It will have the syntax A if C else B.
> 
> I have felt, as Gary Ruben says above, that the range structure is ugly.
> 
> Two alternatives have been suggested:
> a) a:b:c
> b) a..b..c
> 
> Do either of these create parsing problems?
> for i in a:b:
> Should this be treated as an error, with a missing c (the increment)
>  print i
> 
> for i in 2..5:
>  print i                                                           We
> don't know whether the 2 is an integer until the second period is scanned.
> 
> It would be good if the range and slice could be merged in some way,
> although the extended slice is rather complicated - I don't understand it.
> 
>    The semantics for an extended slicing are as follows. The primary
>    must evaluate to a mapping object, and it is indexed with a key that
>    is constructed from the slice list, as follows. If the slice list
>    contains at least one comma, the key is a tuple containing the
>    conversion of the slice items; otherwise, the conversion of the lone
>    slice item is the key. The conversion of a slice item that is an
>    expression is that expression. The conversion of an ellipsis slice
>    item is the built-in |Ellipsis| object. The conversion of a proper
>    slice is a slice object (see section section 4.2 The standard type
>    hierarchy <http://www.network-theory.co.uk/docs/pylang/ref_30.html>)
>    whose |start|, |stop| and |step| attributes are the values of the
>    expressions given as lower bound, upper bound and stride,
>    respectively, substituting |None| for missing expressions.
> 
> [source: http://www.network-theory.co.uk/docs/pylang/ref_60.html]
> 
> The seems to be a bit of a problem with slicing that needs sorting out.
> 
> The syntax for a slice list appears to allow multiple slices in a list:
> 
>    extended_slicing     ::=     primary <primaries.html#tok-primary> "["
>    slice_list <slicings.html#tok-slice_list> "]"
>    slice_list     ::=     slice_item <slicings.html#tok-slice_item> (","
>    slice_item <slicings.html#tok-slice_item>)* [","]
> 
> but the current interpreter reports an error:
> 
>     >>> a= range(20)
>     >>> a[slice(3, 9, 2)]
>    [3, 5, 7]
>     >>> a[slice(3, 9, 2), slice(5, 10)]
>    Traceback (most recent call last):
>      File "<interactive input>", line 1, in ?
>    TypeError: list indices must be integers
>     >>>
> 
> I have taken the liberty of cross posting this to c.l.p.
> 
> Colin W.
This was originally posted to the numpy discussion list.

Colin W.