[Numpy-discussion] Response to PEP suggestions
tkorvola at welho.com
Thu Feb 17 13:01:19 CST 2005
Travis Oliphant <oliphant at 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
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 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
> 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>
More information about the Numpy-discussion