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:
I think that the current behavior has always been possible; arbitrary objects can be passed as indices and coercing to int was always possible.
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.