RE: FW: [Numpy-discussion] Bug: extremely misleading array behavior

[eric j. <er...@en...>]

> From: Perry Greenfield [mailto:pe...@st...]
> <Eric Jones wrote>:
> 
> > Travis seemed to indicate that the Python would convert 0-d arrays
to
> > Python types correctly for most (all?) cases.  Python indexing is a
> > little unique because it explicitly requires integers. It's not just
0-d
> > arrays that fail as indexes -- Python floats won't work either.
> >
> That's right, the primary breakage would be downstream use as
> indices. That appeared to be the case with the find() method
> of strings for example.
> 
> > Yes, this would be required for using them as array indexes.  Or
> > actually:
> >
> >  >>> a[int(x[2])]
> >
> Yes, this would be sufficient for use as indices or slices. I'm not
> sure if there is any specific code that checks for float but doesn't
> invoke automatic conversion. I suspect that floats are much less of
> a problem this way, though will one necessarily know whether to use
> int(), float(), or scalar()? If one is writing a generic function that
> could accept int or float arrays then the generation of a int may
> be overpresuming what the result will be used for. (Though I don't
> have a particular example to give, I'll think about whether any
> exist). If the only type that could possibly cause problems is int,
> then int() should be all that would be necessary, but still awkward.

If numarray becomes a first class citizen in the Python world as is
hoped, maybe even this issue can be rectified.  List/tuple indexing
might be able to be changed to accept single element Integer arrays.  I
suspect this has major implications though -- probably a question for
python-dev.

eric