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 Arfrever, eric.smith, ethan.furman, gvanrossum, larry, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, skrah, terry.reedy, vstinner
Date 2013-12-23.13:29:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thank you everyone for increasing my understanding.  :)

Terry J Reedy wrote:
> [snip everything I now agree with, which is most of Terry's comment]

> 3. Every core usage of __int__ looks for __index__ also. Int() does not
> do this now, but '%d' does [...]
> The exact details would depend on whether we want to allow (or at least
> bless) classes with __int__ and __index__ returning different ints.

I think we should state that __int__ and __index__ are expected to return the same value (if both are defined) otherwise one is on one's own (otherwise known as: if it breaks, you own all the pieces ;) .

> Given things as they are, I would simply expand the domain of %x, etc,
> to that of %d without bothering to go through a deprecation process.

This is not correct.  `hex(3.14)` raises a TypeError, and so should `'%x' % 3.14`

While Terry's option 2 would have to wait for 3.5, is there any reason why fixing the %-formating characters to use __index__ instead of __int__ can't go into 3.4?  That portion seems to be clearly a bug and not an enhancement (the enhancement portions of this ticket can be separated out into another issue).
Date User Action Args
2013-12-23 13:29:10ethan.furmansetrecipients: + ethan.furman, gvanrossum, rhettinger, terry.reedy, mark.dickinson, pitrou, vstinner, larry, eric.smith, Arfrever, skrah, serhiy.storchaka
2013-12-23 13:29:09ethan.furmansetmessageid: <>
2013-12-23 13:29:09ethan.furmanlinkissue19995 messages
2013-12-23 13:29:08ethan.furmancreate