On Thu, Aug 6, 2015 at 2:51 AM, Rustom Mody <rustompm...@gmail.com> wrote:
> And I continue to have no idea what Chris is talking about.
> Here is C printf
>>>> from ctypes import *
>>>> cdll.LoadLibrary("libc.so.6")
>>>> libc = CDLL("libc.so.6")
>>>> libc.printf(b"%s", b"Hello")
> 5
> 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]Sure, if it's callable from within Python. Where is this implemented in CPython? def f(x): return x+2 f(1) There's PyNumber_Add() in abstract.c, which looks for the nb_add slot. That contains a pointer to long_add, which is defined in longobject.c. Is that the same thing as (1).__add__? Not really, but that's kinda what implements the underlying operation. Also, the function is declared as 'static', so I don't think you can find it using ctypes. Adding two Python objects is *not* a function call. It is an operator-controlled action. It's very similar, in many ways, to a method call, but it isn't exactly that, and it certainly isn't the sort of thing that you could tail-call-optimize as the concept applies only to cases where you can actually replace a stack frame. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
