[Numpy-discussion] indexing bug?

[Timothy Hochberg]

On 10/3/07, Christopher Barker <Chris.Barker at noaa.gov> wrote:
>
> Stefan van der Walt wrote:
> >> The current behavior is consistent and well
> >>> defined:
> >>> a[x] == a[int(x)]
>
> This is all possible because of PEP 357:


I think that the current behavior has always been possible; arbitrary
objects can be passed as indices and coercing to int was always possible.

http://www.python.org/dev/peps/pep-0357/
>
> However, when I read this from the PEP:
>
> """
> It is not possible to use the nb_int (and __int__ special method)
> for this purpose because that method is used to *coerce* objects
> to integers.  It would be inappropriate to allow every object that
> can be coerced to an integer to be used as an integer everywhere
> Python expects a true integer.  For example, if __int__ were used
> to convert an object to an integer in slicing, then float objects
> would be allowed in slicing and x[3.2:5.8] would not raise an error
> as it should.
> """
>
> It seems pretty clear that only integer types were intended to by used
> as indexes. Does that make this a bug? I'll defer that to others more in
> the know than I.


As I understand it, the whole point of PEP-357 was to allow the coercion of
int-like things (numpy.int32 say, or your own private integerish class) to
be used as indices without also allowing things that aren't integers, but
that can be coerced to integers (floats for instance) to slip through. So
yes, I'd say this is a bug. Probably someplace that should be using
__index__ or the C equivalent is still using __int__, but I haven't had time
to look.

On the other hand, this may well be a bug that people rely on and it's not
doing drastic immediate harm. So, while I think it should get fixed
eventually, it's probably fine to wait till 1.1 or whenever the next
convenient time is.

-- 
.  __
.   |-\
.
.  tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20071003/ecd8919d/attachment.html>