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. -- http://mail.python.org/mailman/listinfo/python-list
