[Python-ideas] combining two threads: switch statements and inline functions

[Andrew Barnert]

From: spir <denis.spir at gmail.com>

Sent: Wednesday, February 12, 2014 2:12 AM


> What the compiler need, more than the type, is the "weight" (memory 
> size); so as to be able to (statically) reserve slots in the stack (or register, 
> wherever). [In general, static efficiency comes from knowing the weight of 
> values, also at times their structures (say globally their "formats"), 
> rather than their types.]
> 
> At first sight, it seems to me that python's optional and 
> "default" args may also be a big obstacle to inlining. (I wonder how 
> they're done for regular func def and cal, by the way.)


You're still thinking in C terms.

First, in Python, the stack is a stack of objects, not bytes. They all have the same weight and structure (in CPython, each one is a PyObject pointer). 

Meanwhile, a function is an object with attributes, including a tuple of default values, a code object with its own attributes like a tuple of argument names, and so on. The interpreter (in particular, the CALL_FUNCTION bytecode handler) is able to match up arguments and parameters at runtime. 

Also, a frame is an object with attributes, including a reference to the previous frame, not just a chunk of bytes on the stack.

So, there is no "call prologue" compiled into each function. And, more generally, the problems you're expecting just don't exist.

The caller just pushes the function and the arguments and does a CALL_FUNCTION, then gets the return value on the stack. The callee just starts off with its frame's locals already set up, and runs exactly the code you wrote and noting more. How it works is all documented, although scattered in a few different places (the bytecode specs in the dis module docs, the attributes of function and code objects in the inspect module docs, the calls and definitions sections of the reference, and the callable C API). I tried to put a summary together at http://stupidpythonideas.blogspot.com/2014/02/arguments-and-parameters-under-covers.html if it helps.

So, default parameter values are not an obstacle to inlining at all. They're handled at runtime by CALL_FUNCTION just like arguments are. The obstacle to inlining is that you're ultimately trying to inline a runtime object at compile time, which doesn't make any sense. Elsewhere in the thread I explained some ways you could do something similar but sensible, but it's not going to be like C or C++ inlining.