Integrate Python in a C/C++ application

[Alex Martelli]

Cameron Laird wrote:

> In article <Un8xa.105939$3M4.2348947 at news1.tin.it>,
> Alex Martelli  <aleax at aleax.it> wrote:
> .
> [Alex and I both
> think about embedding
> a bunch]
> .
> [interesting stuff to
> which I'll need to re-
> turn later]

Oh yes!  In particular, I'm really interested in learning
what makes you think that embedding is gradually becoming
less important wrt extending -- because I have that
feeling too but can't really articulate the "why"s.

> Disagreements between us are not unfortunate.
> We get to learn, and it's probably entertaining
> for the audience.

True.


> In any case, I disagree that we have a disagree-

I agree;-).

> ment.  You are absolutely right that some existing
> applications are so gnarled as to resist embedding
> within Python.  Both of us have experienced that.
> 
> I know; I'll do a different kind of summary:
> 1.  It's essentially always straightforward
>     to embed Python in an existing application
>     ('know what the toughest issues are?  I/O,
>     on weirdo OSs, and threading-and-events).

Yes -- except that I haven't had experience on weird OS's:
I came to Python late enough that Windows and Unixoid OS's
are the only OS's I've ever used Python on.  Threading can
indeed be messy.

> 2.  Many times that people *think* they want
>     to embed Python, they'd actually be be
>     better off turning the application "inside
>     out", and extending Python with the
>     existing application.  The existing appli-
>     cation might be exposed to Python as a
>     monolith, or it might be factorized more
>     or less profoundly.

Yes -- except that "exposing the existing app to
Python (albeit as a monolith)" is the nontrivial
part.  If the app can be exposed in terms of
making single functionalities from it available
then it's not a hopelessly tangled monolith;-).

> 3.  Some applications aren't worth embedding
>     inside Python.
> 
>     I claim these are fewer than people
>     generally realize, but I completely agree
>     with Alex that the number's greater than
>     zero.

Hmmm, I wouldn't frame this in terms of "not being
worth", though I can see it's a reasonable viewpoint.

The equivalent but alternative viewpoint I'd mention
(particularly to the affectionate owners of said app,
which I might not want to antagonize, what with the
likelihood of their being prospective clients for
some consulting;-) is that if 'embedding the app in
Python' (the "extending" approach) requires extensive
refactoring of the app (to remove tangles etc) then
'embedding Python in the app' may be more feasible
(though not quite as desirable) because you can make
it work and start to show results faster & cheaper --
that may be a must to 'sell' management on the use of
Python in a given organization, sometimes.  "We
need to invest 12 man-months into untangling messes
before we can show you useful results" often doesn't
go down well with management;-).

> 4.  New applications should essentially always
>     be written as the "topless" Python programs
>     Alex described.

*YES*!!!!  Oh [deity of choice] yes!  Moreover you
can generally _at least_ prototype 90%+ of the parts
you need in Python (and existing Python extension
packages and modules) and often find out that more
than half of the 'prototypes' can stay in Python and
save you OODLES of development time -- now THAT is
the kind of thing that management just loves.  It may
be harder to explain to hard-bitten middle managers
of a strongly technical bent, perhaps programmers or
ex-programmers themselves, who have been bitten in the
past by the choice of "shipping the prototype" - but
the fact is that you get a collection of parts and
their solidity depends essentially on having good or
VERY good unit-test and integration-test suites, NOT
on recoding some of them in C++ or Java or whatever --
so you can spend less time AND get better quality by
focusing on the test suites (as early as feasible in
your development cycle -- and that's EARLIER than you
probably think -- not you as in "Cameron", you as "O
generic reader":-).

But anyway, I'm straying (to some extent) from the
subject.  Still, this IS important stuff!!!

> 5.  Web applications are kind of a different
>     story.  More on that, another time.

I'd love to hear your thoughts on this, though!


Alex