Just a small comment: Travis Oliphant wrote:
Capping indexes was proposed because of what numarray does. I can only think that the benefit would be that you don't have to check for and raise an error in the middle of an indexing loop or pre-scan the indexes. But, I suppose this is unavoidalbe, anyway. Currently Numeric allows specifying indexes that are too high in slices. It just chops them. Python allows this too, for slices. So, I guess I'm just specifying Python behavior. Of course indexing with an integer that is too large or too small will raise errors:
In Python:
a = [1,2,3,4,5] a[:20] works a[20] raises an error.
This feature is extremely useful. Just yesterday, I needed some code to check whether the first character in a (potentially empty) string was one of a certain list. I couldn't use .startswith(), because I'd have to call it for each test, and I didn't feel like writing a regexp (since I abandoned Perl coding, I've mostly forgotten them and I need to look up the syntax every time). The danger with: if mystr[0] in ('a','b','c'): ... is that if mystr is empty, this blows up. Thanks to Python's acceptance of invalid indices in slices, I used if mystr[0:1] in ('a','b','c'): ... This is exactly identical to the first case, except that if the string is empty, mystr[0:1] returns ''. No need for extra checks, no need for a try/except block, nothing. Clean, elegant and to the point. Given that python supports these semantics for all their sliceable containers, I'd very much vote for numerix doing the same. There are cases where it makes sense for numerix arrays to have different semantics from python lists. The slice-as-view is probably the best example. But unless there is a strong reason to do so, I think numerix arrays should not deviate from python sequence behavior. Regards, f