[Python-Dev] Inline caveat

[Guido van Rossum]

> > There is, of course, a definite downside to Inline.  Your code will get
> > harder to read and maintain because you and whoever else has to maintain
> > your code has to be familiar with all the languages you are inlining.
> > 
> > Skip
> This is more an argument against mixed language programming
> than against Inline.
> Inline makes it easier (a no-brainer) to locate the code which
> has to be changed, to determine what has to be recompiled,
> where (and how) it has to be installed, and so on.
> 
> I've played a little bit with the idea and I certainly
> like it.
> 
> Thomas

If the alternative is writing an extension module, the inline approach
sounds viable to me.

I could also imagine auto-wrapping existing C functions based on
parseable function signatures.  I believe VB supports this.
Dangerous, but powerful, and very useful in the right hands.

It seems to me that the important idea here is to break away from
building and distributing a separate extension module, which gets you
in the edit-compile-link-test-run loop that Python tries to avoid.
Rather than requiring an expert who knows how to download, build,
install and use SWIG or how to write Python extensions, all the
expertise is automated.

Getting this to work on Windows for the average Windows user would be
a big hassle, limiting the portability and therefore the usefulness.

Of course, Jython already has all this, thanks to Java's introspection
capabilities.  I wonder if the new C++ standard makes enough run-time
type information able to be able to pull of the same trick?

--Guido van Rossum (home page: http://www.python.org/~guido/)