How to write Inline Functions in Python?

[Michael Stenner]

On Mon, Nov 18, 2002 at 12:57:52AM -0800, Brian Quinlan wrote:
> Michael Stenner wrote:
> > I feel like we're going around in circles here.  I'm talking about
> > python.  It looks like 'inline' would produce serious speedups in some
> > cases.  Therefore, it looks like an inline command would not be
> > useless.
> 
> Doing this would be almost impossible because Python name binding is
> done at runtime. For example, how would you compile this?

< excellent examples snipped >

Your point is well made.  It looks like one would have to deviate
extremely far from the "python feel".  It could be done in an
extremely restrictive way, of course, but (as you point out) inline
function objects would not (COULD not) behave like every other python
object does.  They would probably have to be treated like macros and
only have meaning at compile-time.

> Not that an inline keyword should be added to the language even if it
> were possible...

Never said they should :)

On Mon, Nov 18, 2002 at 09:51:58AM +0000, Alex Martelli wrote:
> 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)

< snip >  Summary: g can be anything, and change each time f is called

> 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.

< snipped further discussion of the possible degrees of ugliness >

OK, I'm pretty convinced.  It could by "simple" (as I imagined
it) such that inline functions are like macros.  In this case, they
behave nothing like regular objects (only really existing at
compile-time) and are only usable in very restricted ways.  Or... It
could be "complex" and totally rework the concept of compilation.

I hadn't fully appreciated the complexities introduced by modules.
Basically, I think it comes down to the fact that there _is_ no single
"compile time".  I feel silly for not realizing that.  I've extolled
the benefits of that model many times :)

> 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.

Well, I want to repeat that I _didn't_ propose such changes.  I merely
sought enlightened opinions on the matter.  I saw modest benefit in
the idea, and was curious about _why_ people thought it was a bad
one.  You (and Daniel) have given me precisely what I asked for.

< snipped analogy explaining absolute vs. relative merit >

> 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.

My objection to the word "useless" was not linguistic nit-picking.
Timothy was not (as I understood him) saying that the drawbacks far
outweighed the benefits.  He did not discuss drawbacks at all.  He
said that the benefits were insignificant.

You have said something very different (and the sort of thing I was
asking for).  You have said that the modest benefits are dwarfed by
the costs of implementation and the "ugliness" (for lack of a better
word) introduced.  I find your argument quite persuasive.

Thank you all for the discussion.  That's all I was after.  I
apologize if it ever seemed otherwise.

					-Michael
-- 
  Michael Stenner                       Office Phone: 919-660-2513
  Duke University, Dept. of Physics       mstenner at phy.duke.edu
  Box 90305, Durham N.C. 27708-0305