19

Python's magic method __call__ is called whenever you attempt to call an object. Cls()() is thus equal to Cls.__call__(Cls()).

Functions are first class objects in Python, meaning they're just callable objects (using __call__). However, __call__ itself is a function, thus it too has __call__, which again has its own __call__, which again has its own __call__.

So Cls.__call__(Cls()) is thus equal to Cls.__call__.__call__(Cls()) and again equilevant to Cls.__call__.__call__.__call__(Cls()) and so on and so forth.

How does this infinite loop end? How does __call__ actually execute the code?

jsbueno
  • 77,044
  • 9
  • 114
  • 168
Markus Meskanen
  • 15,203
  • 11
  • 57
  • 106

3 Answers3

17

Under the hood, all calls in Python use the same mechanism, and almost all arrive at the same C function in the CPython implementation. Whether an object is an instance of a class with a __call__ method, a function (itself an object), or a builtin object, all calls (except for optimized special cases) arrive at the function PyObject_Call. That C function gets the object's type from the ob_type field of the object's PyObject struct, and then from the type (another PyObject struct) gets the tp_call field, which is a function pointer. If tp_call is not NULL, it calls through that, with the args and kwargs structures that were also passed to PyObject_Call.

When a class defines a __call__ method, that sets up the tp_call field appropriately.

Here's an article explaining all of this in detail: Python internals: How callables work. It even lists and explains the entire PyObject_Call function, which isn't very big. If you want to see that function in its native habitat, it's in Objects/abstract.c in the CPython repo.

Also relevant is this stackoverflow Q&A: What is a "callable" in Python?.

Community
  • 1
  • 1
BrianO
  • 1,400
  • 8
  • 12
4

There isn't an actual infinite loop, because the __call__ method is not actually invoked ("called") for all of those situations. It's only invoked directly when there is a function-like call on an object that provides a __call__ method.

Normal class instantiation Cls(...) and regular functional invocation f() are known cases that are handled directly. There generally is not an actual invocation of __call__(), so there are a finite number of __call__ method invocations that can ever occur, even in complex cases with deep inheritance, metaclasses, etc.

Because there was some dispute as to whether the short-circuiting of conceptual infinite loops was really happening, let's look at the disassembled bytecode. Consider the following code:

def f(x):
    return x + 1

class Adder(object):
    def something(self, x):
        return x + 19
    def __call__(self, x):
        return x + 1

def lotsacalls(y):
    u = f(1)
    a = Adder()
    z = u + a.something(y)
    return a(z * 10)

Sorry it's a little complex, as I want to show several instances of short-circuiting--namely, normal def functions, __init__ calls, normal methods, and __call__ special methods. Now:

annotated disassembly

So here are a range of times when, if Python were really, truly "walking the tree" of conceptual __call__ invocations, it would to reference Function (and possibly Method classes, and invoke their __call__ methods). It doesn't. It uses the simple bytecode CALL_FUNCTION in all cases, short-circuiting the conceptual tree-walk down. Logically you can imagine that there is a class Function that has a __call__ method that's invoked when a function (i.e. an instance of the Function class) is called. But it doesn't really work that way. The compiler, bytecode interpreter, and other parts of the C-language underpinnings do not actually walk meta-class trees. They short-circuit like crazy.

Jonathan Eunice
  • 17,488
  • 6
  • 66
  • 70
  • 1
    But functions themselves are just "objects that provide `__call__` method", including `__call__` itself. Thus to invoke `__call__`, you call its `__call__` which again calls its `__call__`. Where does the line go, and what is it based on? – Markus Meskanen Sep 30 '15 at 00:49
  • 1
    No, they're actually not. *Conceptually* they can be viewed as "just objects that provide __call__ method," but actually they are directly understood by the compiler and runtime, and directly implemented. It's just like the Fibonacci Sequence, say. Yes, there is a completely recursive definition, and possible implementation. But most actual implementations are iterative. They short-circuit the logical recursion, so as to not have to laboriously go through long recursion chains. – Jonathan Eunice Sep 30 '15 at 00:54
  • I'm not saying you're wrong, because I don't know for sure, but can you prove that? They seem like normal objects to me, and BrianO's answer with links to source code and all seems to support my theory. I'm not saying I'm right and you're wrong, but to me it currently looks like they're just objects and it's the C implementation that calls the `__call__` only once, if one has been defined. – Markus Meskanen Sep 30 '15 at 14:00
  • Sure. I added annotated disassembler output that shows almost all of the cases you imagine as being invocations of `__call__` on some meta-class are in fact not literally present. The compiler and bytecode engine are not deep-walking any class hierarchies or meta-class trees. – Jonathan Eunice Sep 30 '15 at 17:18
  • This isn't to say there are *no* situations where more meta-objects get involved (for example, when pure-Python metaclasses are provided, or when there's a deeper inheritance structure). But in all the typical cases, short-circuiting rules the land. – Jonathan Eunice Sep 30 '15 at 17:20
1

I didn't check any documentation, but from my tests it seem __call__ isn't always called:

def func1(*args, **kargs):
    print "func1 called", args, kargs

def func2(*args, **kargs):
    print "func2 called", args, kargs

func1.__call__ = func2

func1() # here is still called func1

class Cls:
    def __init__(*args, **kargs):
        print "init called", args, kargs
    def __call__(*args, **kargs):
        print "object called", args, kargs

obj = Cls() # here is actually called __init__
obj()  # here is called __call__

this prints

func1 called () {}
init called (<__main__.Cls instance at 0x0000000002A5ED88>,) {}
object called (<__main__.Cls instance at 0x0000000002A5ED88>,) {}
gre_gor
  • 5,546
  • 9
  • 35
  • 41
  • With `obj = Cls()` notice that `Cls` is just an instance of `type`, so that would be equal to `type.__call__()`. (Google: metaclasses). Although the first finding is interesting, anyone know why `func1.__call__` is not invoked? – Markus Meskanen Sep 30 '15 at 01:02
  • @gre_gor Beautifully empirical demonstration that function calls are special-cased! – Jonathan Eunice Sep 30 '15 at 01:02
  • @MarkusMeskanen Yes. `func1.__call__` is not invoked because it's a special case. Python does not need to traverse the full concept of "functions are just objects," because this is a very common, well-known situation the complier/runtime can handle more directly. There are **many** instances of such shortcuts in the Python implementation. Python aims for high level semantics, but it often jumps down into special cases and C code for performance. – Jonathan Eunice Sep 30 '15 at 01:05
  • 6
    Generally speaking, `__special_methods__` don't get called if they're instance variables. They're only called if they're in the class of an object. So, assigning to `func1.__call__` doesn't do anything useful. – Blckknght Sep 30 '15 at 01:28
  • 1
    @Blckknght Thanks, that makes sense! So functions too are just normal objects and not "special cases" :P – Markus Meskanen Sep 30 '15 at 14:01