On Wednesday, August 5, 2015 at 10:29:21 AM UTC-6, Chris Angelico wrote: > On Thu, Aug 6, 2015 at 2:10 AM, Rustom Mody <rustompm...@gmail.com> wrote: > > 1 + x > > does not *call* 1 .__add__(x) > > It *is* that > > [Barring corner cases of radd etc] > > IOW I am desugaring the syntax into explicit method-calls so you can see > > all the calls explicitly > > Then it becomes evident -- visibly and in fact --that the tail call is the > > __add__ method not the solderdiersVsDefenders > > Except that it *isn't* that, precisely because of those other cases. > When Python sees an expression like "1 + x" and doesn't yet know what > x is, it can't do anything other than record the fact that there'll be > a BINARY_ADD of the integer 1 and whatever that thing is. That object > might well define __radd__, so the call is most definitely not > equivalent to the operator. > > And the ultimate result of that addition might not even be a function > call at all, if it's implemented in C. Or if you're running in PyPy > and the optimizer turned it into machine code. So no, even though you > can define addition for *your own classes* using __add__ or __radd__, > you can't reinterpret every addition as a function call. > > ChrisA
Good (intricate) point. -- https://mail.python.org/mailman/listinfo/python-list
