[Python-Dev] Semantics of __int__(), __index__()

Ethan Furman ethan at stoneleaf.us
Wed Apr 3 21:36:58 CEST 2013

On 04/03/2013 12:21 PM, Tres Seaver wrote:
> Hash: SHA1
> On 04/03/2013 01:50 PM, Ethan Furman wrote:
>> On 04/03/2013 10:46 AM, Barry Warsaw wrote:
>>> On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
>>>> On 04/04/13 01:16, Barry Warsaw wrote:
>>>>> the other built-in types-as-functions, so int() calls __int__()
>>>>> which must return a concrete integer.
>>>> Why must it? I think that's the claim which must be justified, not
>>>> just taken as a given.  When we call n = int(something), what's
>>>> the use-case for caring that n is an instance of built-in int but
>>>> not of a subclass, and is that use-case so compelling that it must
>>>> be enforced for all uses of int() etc.?
>>> It's a consistency-of-implementation issue.  Where built-in types
>>> are callable, they return concrete instances of themselves.  This is
>>> true for e.g. list, tuple, dict, bytes, str, and should also be true
>>> of int.
> Given that requirement, we still don't have to mandate that __int__
> return an actual instance of the int type:  the coercion could happen
> inside int() (as it would for any non-subclass).

I don't understand.  A non-int could only become an int via __int__, which int() calls.  What magic is there in int() to 
turn any arbitrary object into an integer?

--> class NonInt():
...   def __str__(self):
...     return "Not an integer!"
--> ni = NonInt()
--> ni
<__main__.NonInt object at 0x267a090>
--> str(ni)
'Not an integer!'
--> int(ni)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not 'NonInt'


More information about the Python-Dev mailing list