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

[Ron Adam]

On 02/12/2014 05:50 PM, Andrew Barnert wrote:
> 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
> athttp://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.

Right, Think in byte code not python source code.

It should be possibly to define a limited type of function that has a code 
object which is insert-able into in the byte code, but it would have some 
pretty limited restrictions.

    *  Take no arguments.
    *  Have all variables declared as non-local.
    *  Not access any closure names.
    *  Insure there is no executable code after any return location.

The the call could be removed and the code in the code object could be 
inserted at that location, and the returns removed so the return value is 
left on the stack.

That isn't a common pattern, so it's not very useful.  And probably not 
worth implementing without expanding on that in some way.

Ron