How to write Inline Functions in Python?

[Alex Martelli]

Delaney, Timothy wrote:
   ...
> But none of this has anything to do with *inline functions* which is what
> the original poster asked about. A language which (supposedly) gets so
> close to the metal as to expose the implementation details of the code
> produced (such as via an "inline" hint) *should* these days have
> highly-optimising compilers. If your compiler does not have such
> optimisations, then the "inline" hint is probably useless. If it *does*
> have such optimisations, then the "inline" hint is also probably useless.

I don't entirely agree wih this very general statement, although it may
well apply to the specific case of 'inline'.

I think it might be quite sensible for a language to allow the human
programmer to state RESTRICTIONS that the programmer intends to follow
with respect to the more general semantics of the language in a specific
case -- even when the language's compiler should _theoretically_ be
able to infer those restrictions by examining all of the involved
source code, it may still be much more practical instead to have the
task just be one of CHECKING that the restrictions are indeed obeyed
(when the checking is feasible), as well of course as then potentially
going on to exploit the optimization possibilities that follow from
the restriction.

To make a trivial example -- "inline" might just be a peculiar spelling
to mean "I promise never to take the address of this" (I know C++'s
"inline" is different, but that's close to what "register" meant in
some C compilers).  Sure, sure, the compiler can find out for itself
what functions or variables ARE subjected to the address-of operator
and which aren't -- but at some stage of compiler development, machine
power, and times allowable for compilation and optimization, not
having to find out MAY in practice mean the difference between a
practically feasible optimization and one that isn't.

So perhaps in some hypothetical future Python, "inline" might just mean
"I promise never to re-bind this name: it will refer to the SAME object 
each and every time you look it up, forever and ever, amen".  It might then 
be preferable to spell it otherwise than 'inline', admittedly.  But 
'inline' might be once concise choice.  It would then be up to the compiler 
to check that the restriction is true (e.g. running in debug mode, doing 
the lookup again every time but emitting a warning or exception if the 
restriction is not being respected) and/or optimize based on that 
restriction (saving the lookup might be juicy enough, but possibly 
"inserting inline expansion" when feasible at the first occurrence might 
also be a possibility).


> Humans have been shown time and again to be exceptionally bad guessers as
> to what needs optimising. As such, humans should concentrate on making
> their code as clear and readable as possible, and let the automated
> systems (such as a compiler) work out what is the best optimisation.

Yes, but the language could help both the human AND the compiler from a 
pragmatical point of view, by making it possible to state restrictions 
(particularly ones that may allow optimizations) "clearly and readably".


Alex