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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4