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

Tres Seaver tseaver at palladion.com
Wed Apr 3 21:21:59 CEST 2013

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).

- -- 
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/


More information about the Python-Dev mailing list