On Sat, Nov 2, 2019 at 1:54 PM Nick Coghlan <ncogh...@gmail.com> wrote:
> > > On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, <gu...@python.org> wrote: > >> 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? I'd say >> looking for __trunc__ if the alternative is failing isn't so bad. >> > > Aye, converting a case where code is slower than it needs to be to an > outright failure isn't a good trade-off. > I find int() falling back to __trunc__() surprising, actually. Removing it will break backwards-compatibility, but implementing __int__() is an easy fix. Perhaps we could run a code search for classes implementing __trunc__ but not __int__? Speeding up int(str), as well as slightly simplifying the language, are rather good arguments in favor of this. - Tal
_______________________________________________ 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/NPUG2SJKNPCX6ECCVJY3W2RC4PXF6MLP/ Code of Conduct: http://python.org/psf/codeofconduct/
