Travis Oliphant <oliphant@ee.byu.edu> writes:
Currently Numeric allows specifying indexes that are too high in slices. It just chops them. Python allows this too, for slices.
Yes, since foo[:] just means foo.__getitem__(slice(sys.maxint)). Slices even have a nice method for normalizing the indices.
So, I guess I'm just specifying Python behavior.
Not really: your specification causes an element with a different index to be returned, whereas the usual slice behaviour only causes out-of-range indices to be omitted from the result.
3) Always returning rank-0 arrays.
This may be a bit controversial as it is a bit of a change.
Indeed. So you really do intend that if foo=array([1,2]), foo[0] should evaluate to array(1) rather than 1?
But, my experience is that quite a bit of extra code is written to check whether or not a calculation returns a Python-scalar
I suppose this may be necessary for code which operates on arrays of somewhat arbitrary rank and would not know without looking whether, e.g., foo[0] is a scalar or an array of positive rank.
In particular len(a) does not work if a is a scalar,
Depends on what kinds of scalars are supported. What about object arrays?
but len(b) works if b is a rank-0 array
It does? In Numarray len(b) raises ValueError and size(b) returns 1. To me this would seem the correct behaviour.
When Python needs a scalar it will generally ask the object if it can turn itself into an int or a float.
Hence this change might not be as incompatible as it seems, although users of object arrays would be in for some surprises.
I'd like to know what reasons people can think of for ever returning Python scalars unless explicitly asked for.
It would be more consistent with the usual container semantics and less likely to break existing code. -- Timo Korvola <URL:http://www.iki.fi/tkorvola>