Author josh.r
Recipients josh.r
Date 2018-03-05.21:07:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>
In-reply-to
Content
In Python 2, making a user-defined class support formatting using the integer-specific type codes required that __int__ be defined and nothing else (that is, '%x' % Foo() only required Foo to provide a __int__ method). In Python 3, this was changed to perform the conversion via __index__ for the %o, %x and %X format types (to match how oct and hex behave), not __int__, but the pre-check for validity in unicodeobject.c's mainformatlong function is still based on PyNumber_Check, not PyIndex_Check, and PyNumber_Check is concerned solely with __int__ and __float__, not __index__.

This means that a class with __index__ but not __int__ can't be used with the %o/%x/%X format codes (even though hex(mytype) and oct(mytype) work just fine).

It seems to me that either:

1. PyNumber_Check should be a superset of PyIndex_Check (broader change, probably out of scope)

or

2. mainformatlong should restrict the scope of the PyNumber_Check test to only being used for the non-'o'/'x'/'X' tests (where it's needed to avoid coercing strings and the like to integer).

Change #2 should be safe, with no major side-effects; since PyLong and subclasses always passed the existing PyNumber_Check test anyway, and PyNumber_Index already performs PyIndex_Check, the only path that needs PyNumber_Check is the one that ends in calling PyNumber_Long.
History
Date User Action Args
2018-03-05 21:07:14josh.rsetrecipients: + josh.r
2018-03-05 21:07:14josh.rsetmessageid: <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>
2018-03-05 21:07:14josh.rlinkissue33002 messages
2018-03-05 21:07:13josh.rcreate