On Wednesday, August 5, 2015 at 10:11:30 PM UTC+5:30, wrote:
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 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.

Good (intricate) point.

And I continue to have no idea what Chris is talking about.
Here is C printf
from ctypes import *
libc = CDLL("libc.so.6")
libc.printf(b"%s", b"Hello")

As far as I can see printf is a C function and its behaving like (an
ill-behaved) python function as well.
Likewise for anything else written ina C extension module
Or a C-builtin

If its callable from within python its python
That it may also be C seems to me beside the point
[As I said I dont get the point]

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 12 | next ›
Discussion Overview
grouppython-list @
postedAug 5, '15 at 3:13p
activeAug 5, '15 at 5:10p



site design / logo © 2018 Grokbase