[Numpy-discussion] Re: number ranges (was Re: Matlab page on scipy wiki)

[Colin J. Williams]

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.