[Numpy-discussion] Response to PEP suggestions

Timo Korvola tkorvola at welho.com
Thu Feb 17 13:01:19 EST 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[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

> 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 mailing list