Integrate Python in a C/C++ application

[Alex Martelli]

Cameron Laird wrote:
   ...
>>Incidentally, Bertrand Meyer (even though the language he invented,
>>Eiffel, is SO drastically different from Python, Ruby etc) had it right
>>when he claimed that "a real system has no top".  If your application
   ...
> I'm going to say some of the same things as Alex, but in
> a different way, that perhaps a few readers will find
> helpful.

Quite possibly -- I _do_ appreciate your knack for concise
and clear expression!


> Alex is correct:  Lua's easier to embed than Python, but
> both are easy, you should expect to be successful embed-
> ding Python, and so on.
> 
> Five or ten years ago, embedding was more important than
> it is now.  Alex is right:  any time you feel like em-
> bedding, you should stop and consider whether you can
> simply create a Python (or Lua or ...) application, which
> exploits your existing C-coded objects.  Turn your appli-

Interesting.  I would like to understand how and why
embedding (as opposed to 'pure extending' of Python, i.e.
exposing your existing code to Python as extension modules)
has become less important in recent years.  I do have
some vague feeling that confirms this assertion, but I
couldn't really substantiate it.

> cations inside-out.  You do NOT have to "buy into" or
> even understand his "go topless" argument, nor fret over
> "component" or "object" theory.  Put it on this basis:
> if it's at all feasible for Python to "be in charge",
> then make it so.

I do fully agree that no fretting is needed nor warranted.

Even if the reusable part of your application is coded in
terms of pure procedural logic -- all function calls with
primitive data types and arrays thereof as arguments -- it
is still feasible and useful to expose it to Python.  If
the reusable part of your application is coded in an
object-oriented way, that will be even easier and more
fruitful, but, if not, Python itself can be used to package
things up into objects as and when useful (witness the many
procedural modules in the standard Python library, including
new ones such as heapq, introduced only with 2.3 -- while
object-oriented purists fret about them no end, us Python
pragmatists put them to good and productive use anyway --
sometimes 'packaging them up' as objects, sometimes not).

And I'll freely confess I was using "components" in the good
old generic sense of the word, before it was (as so many
other words have been...) 'hijacked' to have some precise
technical meaning (or, often, more than one:-)...


> I'll summarize:  Alex is right.  What he didn't say is
> that times have changed, and old reasons for embedding
> have gone away (I'm postulating this, now, without
> explanation; details available, if necessary).  More-

I'm not sure the details are _necessary_, strictly speaking,
but I'm sure curious about what you think the old reasons
were and what has made them go away.

> over, I don't want his correct description in terms of
> "components" to frighten anyone.  You don't have to
> work hard.  Take the one step of turning your applica-
> tion "inside out", and you'll find, quite often, that
> you're best off with Python in charge.

Hmmm -- unfortunately, I do think we may have a slight
disagreement here.  I _have_ in the recent past worked to
try and make monolithic applications into freely reusable
sets of components "without a top", and I sure DID have
to work hard, and without achieving in some cases what I
would consider entirely satisfactory results.  When a big
application is designed and evolved as a monolithic entity,
without any thought to making any of its parts separable
and reusable, there's some kind of natural tendency for all
parts of the application to develop extremely strong coupling,
nasty complicated graphs of dependency connections that are
not acyclic nor at all easy to untangle, and so on.  Total
meshing of business-logic and presentation issues is a typical
symptom of this kind of mess -- e.g applications that just
can't be made to perform some necessary _computation_ unless
and until they can first build up their [expletive deleted]
graphical user interfaces (and it would appear to me that
this blight has been perpetuated in recent years by many
coders' delight in "embedding their code in HTML", a highly
doubtful architecture that's nevertheless strongly encouraged
by such architectures as PHP's and ASP's).

So, I'm playing the old pessimistic curmudgeon and claiming
that many legacy applications will unfortunately present
this kind of issues.  If and when they do, and rearchitecting
the whole thing is too much of an investment to make right
now, then some minor clean-up (substantially less investment
than necessary to "let Python be in charge", as would no
doubt be always preferable _if_ cheaply achievable) can still
let you _embed_ Python and thereby obtain SOME level of
enhancement and increased functionality in the application.

The experience of trying to rearchitect a monolithic mess
(with global state, logic/presentation intermeshing, and
the like) into something cleaner and more usable will, one
hopes, encourage future applications to be architected in
_non_-monolithic ways (it's really not at all harder than
doing the big-messy-soup thing, if done right from the start;
it's just harder to get _away_ from that quicksand if you've
allowed it to suck you in in the first place:-).


Alex