How to write Inline Functions in Python?

Alex Martelli aleax at aleax.it
Mon Nov 18 04:51:58 EST 2002


Michael Stenner wrote:
   ...
> I'm not convinced that it would be "worth it" to have "inline
> functions" or "auto-inlined code" or whatever you want to call it.
> That's what I'm trying to discuss.  I'm interested in your (and
> others') thoughts on the matter.  So far though, I find your claims
> that they would be useless unconvincing.

Let's try another tack -- how would it work?

def f(x):
    return g(x+1)

right now, the Python compiler is not ALLOWED to assume, when compiling 
this code, that name 'g' refers to whatever it's referring "RIGHT NOW", 
i.e., at compile-time -- indeed at the time the compilation is taking
place it's quite usual and typical for name g to be undefined-yet.

Python's semantics guarantee that g will be looked up AT RUN-TIME and call 
whatever callable is bound to name 'g' at the time of each call to f, quite 
possibly a different one each time.  g need not be a function -- it might
be an instance of any callable class, and then quite likely might be a
different instance upon different calls to f.

OK so far?  This is where we're starting from.  Now, what black magic
would you be willing to put up with, to enable the user to state that
g should not be called (despite the presence of the call-operator
"open and close parens":-) but rather "expanded"?  That's the issue
as I see it.

If g is a qualified name, as it often will be when using functions
defined in another module:

def ff(x):
    return gmod.gfun(x+1)

it becomes even murkier.  Do you think the huge irregularity
involved in "inline is only allowed for functions whose def
statement precede the inline-use in this very module" would be
an acceptable price to pay, for whatever modest benefits you
think having the compiler inline things rather than having to
do that yourself might bring?  The discussion needs to be split
in two alternative threads depending on this crucial decision.

If "inline" must only apply to functions whose "def" statement
is in this very module, then its miniscule applicability will
substantially reduce the benefits.  The costs in terms of
making the language more complicated are still there (nowhere
as large as in the more general case): defining precisely what
happens to scoping, who if anybody is allowed to rebind global
name 'g' in this module and what happens if they try, what
happens when the function object bound to name g is used in
any other way except calling it immediately, etc, etc.

If "inline" is to be of any measurable usefulness and therefore
also apply to functions imported from other modules, then we
need to introduce an entirely new concept of "compiletime
import" (as well as dealing with all the issues mentioned in
the above paragraph, further complicated by having to deal with
the various level of names in a qualified name).

Summarizing, my working hypothesis is NOT "inline would be
TOTALLY useless"; rather, it is, for either possible choice
regarding what functions inlining could apply to, the costs
and complications would be SO huge compared with the possible
benefits that it almost defies belief that somebody would
propose such changes in earnest.

Analogy: suppose the UN came up with a plan to distribute a
small piece of mint candy to every single person in the world.

Would that be COMPLETELY useless?  No: SOME people in the
world like mint candy, or have never been able to taste it
(being appallingly poor) and would like it if they could; so,
ignoring the costs for an instant, overall human happiness
MIGHT be ehanced by implementing such a plan (despite the risks
of some people misusing their candy, e.g. by eating it when
they have diabetes and shouldn't) -- it's at least possible.

However, the costs and complications are so obviously huge --
just the logistics involved are staggering -- compared with
the miniscule benefits, that it defies belief that anybody
would seriously entertain such a notion in earnest, particularly
when thinking of the many other obvious ways those enormous resources
might be used, could they be summoned, to enhance overall human happiness 
(e.g. by fighting hygiene problems, illnesses, and malnutrition, rather 
than focusing all of those resources on distributing mint candy).

So, I would not feel moved to criticize somebody who described such a plan 
as "useless", even though the term is not strictly and literally applicable.


Alex




More information about the Python-list mailing list