01.11.19 00:03, Guido van Rossum пише:
It seems a good idea to add __int__ to Fraction, but if you stop falling back to __trunc__, won't that cause backwards compatibility issues?
Most numeric types (int, float, Decimal, NumPy types) implement both __trunc__ and __int__. The only known exception is Fraction. So after adding __int__ to Fraction and with a deprecation period the possibility of backwards compatibility issues is pretty low.
I'd say looking for __trunc__ if the alternative is failing isn't so bad.
__trunc__ is looked after __int__ and __index__. But it is looked before type checks for str, bytes, bytearray and buffer protocol. This slows down integer parsing. Getting rid of __trunc__ could speed up int('123').
Other possible benefit is that it would allow to check ahead whether the object can be converted to int. Checking tp_as_number->nb_int and tp_as_number->nb_index is cheaper than looking up __trunc__ in the type dict and never executes Python code.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IR7SXB3TL6RLPJBZ7ZCKISW3GSDSOBCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
