[Python-Dev] boxing and unboxing data types

[Serhiy Storchaka]

On 09.03.15 06:33, Ethan Furman wrote:
> I guess it could boil down to:  if IntEnum was not based on 'int', but instead had the __int__ and __index__ methods
> (plus all the other __xxx__ methods that int has), would it still be a drop-in replacement for actual ints?  Even when
> being used to talk to non-Python libs?

If you don't call isinstance(x, int) (PyLong_Check* in C).

Most conversions from Python to C implicitly call __index__ or __int__, 
but unfortunately not all.

 >>> float(Thin(42))
42.0
 >>> float(Wrap(42))
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: float() argument must be a string or a number, not 'Wrap'

 >>> '%*s' % (Thin(5), 'x')
'    x'
 >>> '%*s' % (Wrap(5), 'x')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: * wants int

 >>> OSError(Thin(2), 'No such file or directory')
FileNotFoundError(2, 'No such file or directory')
 >>> OSError(Wrap(2), 'No such file or directory')
OSError(<__main__.Wrap object at 0xb6fe81ac>, 'No such file or directory')

 >>> re.match('(x)', 'x').group(Thin(1))
'x'
 >>> re.match('(x)', 'x').group(Wrap(1))
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
IndexError: no such group

And to be ideal drop-in replacement IntEnum should override such methods 
as __eq__ and __hash__ (so it could be used as mapping key). If all 
methods should be overridden to quack as int, why not take an int?