This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan.furman
Recipients eric.smith, ethan.furman, gvanrossum, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, skrah, vstinner
Date 2013-12-16.15:42:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1387208530.39.0.478755317431.issue19995@psf.upfronthosting.co.za>
In-reply-to
Content
Victor Stinner commented:
-------------------------
> I never understood the difference between "long" (__int__ method)
> and "index" (__index__ method). Is the difference on the behaviour
> of floating point numbers?

__index__ was originally added so that non-int integers, such as NumPy's int16, int32, etc, integer types could be used as indices and slices.

Now it means "if your type can produce a lossless integer, use __index__", which is why float and similar types don't define it.

The current meaning is unfortunate in that it is possible to want a type that can be used as an index or slice but that is still not a number, and in fact won't be used as a number in any scenario _except_ bin(), hex(), and oct().

It seems to me that by having those three functions check that the argument is a number, and bailing if it is not, is a decent way to ensure consistency.

One question I do have, since I don't have NumPy installed, is what happens with:

  --> "NumPy's int's work here? %x" % uint16(7)
History
Date User Action Args
2013-12-16 15:42:10ethan.furmansetrecipients: + ethan.furman, gvanrossum, rhettinger, mark.dickinson, pitrou, vstinner, eric.smith, skrah, serhiy.storchaka
2013-12-16 15:42:10ethan.furmansetmessageid: <1387208530.39.0.478755317431.issue19995@psf.upfronthosting.co.za>
2013-12-16 15:42:10ethan.furmanlinkissue19995 messages
2013-12-16 15:42:10ethan.furmancreate