On 10/3/07, Christopher Barker <Chris.Barker@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:

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.