[Python-Dev] Semantics of __int__(), __index__()
Tres Seaver
tseaver at palladion.com
Wed Apr 3 21:21:59 CEST 2013
-----BEGIN PGP SIGNED MESSAGE-----
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.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlFcgVcACgkQ+gerLs4ltQ4ScwCfScssK/Cv74lPitQxbygmk5h/
RGoAnj2yUEgmEgorJi8GZh0GEB/iJrN1
=0I+y
-----END PGP SIGNATURE-----
More information about the Python-Dev
mailing list