Python embedding & question about autoconf and dynamic linking

Ken Seehof kseehof at neuralintegrator.com
Thu Oct 4 03:13:40 EDT 2001


> Yes, I found that web site last week.
> The reason for us to do embedding rather than extending is that our main
> applciation is written in C (would you write a router in Python?...) and
we
> use python for writing a re-usable component, that is a CLI component.
> Debugging our application is a lot easier if we embedd the Python code,
which
> represents a small percentage of our application code size. This is
because
> we can use the debugger as usual. If we were embedding our router in a
> Python application (a hell of an extension), we would need to debug the
python
> interpreter, put a breakpoint where it loads extensions, continue until
> it loads our router and then put a breakpoint in our router code.
> Why do I not feel comfortable telling my colleagues who never used Python
to
> do this?

Well I suppose it depends on how fancy your debugger is.  I have no trouble
at all debugging extensions using MSVC++ on windoze.  I debug the extension
as a DLL and set the command line to "python myapp.py ...".  Setting
breakpoints is just as easy as with an executable and this can even be done
before starting the application, so I don't have to take any of the extra
steps you are talking about, and I certainly don't need to debug the
interpreter.  I don't know if you are in windoze or *nix, but I'd assume the
more fancy *nix debuggers can do this too.

Sometimes I have a python debugger and a C++ debugger running at the same
time, and set breakpoints in both!  You can even step through python code
and -kablam- your C++ debugger pops up in the extension code.  It's really
fun once you get used to it.

Sometimes it does make more sense to embed than extend, but usually
extending makes more sense, because the high level parts of a program (user
interface, architecture, rules, data processing) really should be written in
a high level language.  Performance critical code, hardware specific code,
etc. can usually be reduced to a set of low-level functions in C++ (C is
arguably just as good since you usually don't need much object oriented
design at this level).

The only time I have used embedding was on an existing large application
that already had a user interface, to add python as a built in scripting
language.  Generally, embedding involves extending since you usually need to
expose your application to the embedded interpreter.

- Ken  kseehof at neuralintegrator.com

> On Mon, 1 Oct 2001, Mads Bondo Dydensborg wrote:
>
> > On Mon, 1 Oct 2001, Olivier Deme wrote:
> >
> > > > I think it is more common to extend Python, than to embed it. I knew
> > > > nothing about Python (apart from the name) a week ago, so I may be
wrong
> > > > though.
> > >
> > > Same for me. :-)
> >
> > I just found this page
> > http://www.mcmillan-inc.com/embed.html
> >
> > Hmm.
> >
> > Mads
> >
> > --
> > Mads Bondo Dydensborg.
madsdyd at challenge.dk
> > You know you're a Linux geek when...
> >
> >     You can reconstruct your fstab from scratch, and not even think
about it.
> >
> >                                                      - segfault
> --
> http://mail.python.org/mailman/listinfo/python-list





More information about the Python-list mailing list