On Sun., 3 Nov. 2019, 3:29 am Tal Einat, <talei...@gmail.com> wrote: > 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. >
This is exactly the kind of change that prompted Victor to write PEP 608: seeing a compatibility break as our first option rather than as a last resort. Each one is cheap on its own, but collectively they make supporting new CPython versions more painful than it really needs to be. > 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. > In this specific case, they're not particularly strong arguments. * For performance, there shouldn't be any problem with making the check for __trunc__ the very last conversion tried. That will still speed up all successful int conversions that currently incur the cost of checking for a non-existent __trunc__ method, and could only cause a compatibility issue for obscure cases where a type that defines __trunc__, but not __int__, gives a different answer when handled via one of the type-specific conversions instead. * For simplification, "versions up to X allow A, versions after X only allow B" is never actually simpler, it's always more complex than just leaving things alone. It's just that the cost is sometimes worth it when the status quo is causing actual code correctness bugs. However, what could genuinely be simpler in this case (as discussed in https://bugs.python.org/issue33039 and https://bugs.python.org/issue20092) is to move the fallback logic to type creation time rather than requiring that it be implemented in every function that accepts Integral types as input. That logic would be: * if __index__ exists, make __int__ and __trunc__ wrappers around that if they don't already exist * if __int__ exists, but not __trunc__ or __index__, make __trunc__ a wrapper around __int__ * if __trunc__ exists, but not __int__ or __index__, make __int__ a wrapper around __trunc__ With that logic in place, consumers could just call whichever API made the most sense for their use case, and trust the type machinery to provide any appropriate fallbacks. Cheers, Nick. > - 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/UKTMEBPM5HTDKMCBIJYHPILH4X4EEKPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
