Integrate Python in a C/C++ application

Cameron Laird claird at lairds.com
Fri May 16 13:03:38 EDT 2003


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]
			.
>> "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.
			.
			.
			.
>> 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
			.
			.
			.
Disagreements between us are not unfortunate.
We get to learn, and it's probably entertaining
for the audience.

In any case, I disagree that we have a disagree-
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).
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.
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.
4.  New applications should essentially always
    be written as the "topless" Python programs
    Alex described.
5.  Web applications are kind of a different
    story.  More on that, another time.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html




More information about the Python-list mailing list