Embedded Tcl for Python

Michael P. Reilly arcege at shore.net
Mon Jun 28 11:57:29 EDT 1999


Paul Duffin <pduffin at mailserver.hursley.ibm.com> wrote:
: Robin Becker wrote:
:> 
:> In article <3760F0A1.1DDC at mailserver.hursley.ibm.com>, Paul Duffin
:> <pduffin at mailserver.hursley.ibm.com> writes
:> >Michael P. Reilly wrote:
:> >>
:> >> A few weeks ago, someone asked if there was a Tcl module for Python.
:> >> People responded (including myself) that Tkinter uses a Tcl/Tk
:> >> interpreter, but you couldn't get rid of the annoying window.
:> >>
:> >> I've since written an extension ("pytcl") that creates Tcl interpreter
:> >> objects.  As part of that, I have also rewritten _tkinter to use these
:> >> new objects.
:> >>
:> >> I've had a short discussion with Guido and he's interested in the
:> >> idea.  Now I need some alpha testers; I only have access to UNIX boxes,
:> >> and very few types at that.
:> >>
:> >> The _tkinter module has the same functionality as before, including the
:> >> same threading issues.  I've include Deiter's Tcl/Tk8.1 patch but have
:> >> not had the opportunity to test that yet (right not it is just do-no-
:> >> damage).
:> >>
:> >> Contact me at arcege at shore.net if you are interested in helping me test
:> >> these modules.
:> >>
:> >
:> >I was interested in doing something similar in Tcl (e.g. creating a
:> >python interpreter object) and I was wondering if someone could give
:> >me some pointers as to how to go about doing it.
:> >
:> Paul I created a socket linked python interpreter and have used it with
:> reasonable success from Tcl. Latest code is at
:> 
:> http://www.jessikat.demon.co.uk in the file pyserver.zip
:> 
:> this may not be as efficient as havin the in core thing, but gets round
:> the problem of threading model problems etc.

: Thanks Robin, I will take a look at that, have you got any information
: on the threading model problems as I have not yet looked into Python
: threading. I must admit I was amazed that Python does not support
: being built as a shared library and can think of no practical reason why
: not as Python does support dynamically loadable extensions.

: Have any Pythoneers out there done this as it is very useful ?
: If you have any questions as to how useful it is you just need to look
: at Tkinter which could not be dynamically loadable (it is isn't it)
: without Tcl and Tk being dynamically loadable.

Python supports dynamically loadable extensions.  Simply uncomment the
"*shared*" line in Modules/Setup and recompile.  Tkinter (or more
correctly _tkinter) can be dynamically loadable (ie a shared object)
with libtcl.a and libtk.a - in fact, I would suggest it; you do not
have to set the LD_LIBRARY_PATH at runtime if compiled with the static
libraries.

You might be referring to the fact that Python does not create a shared
object of its library, libpython1.5.a.  It could be accomplished fairly
easily (I've never needed to try), but it is often better to make it a
static library.

Static libraries are created from ar(1) (yes, the parent of tar).  The
contents of libraries are the object files themselves, unaltered.  When
linking to create an executable, if a symbol is found in one object
file, then that object file is linked in.  If only one function is
referenced in an object file with one hundred functions, all the
functions are included in the executable, even if none are ever
called.

Since a shared object is a special form of an object file, it follows
the same rules.  If one function or global variable is referenced in
the shared object, then all of the shared object is included in the
executable.  Again even if functions or variables will never be
accessed, they will be included in the program.

Right now, the static library for Python 1.5.2 on AIX 4.2.1 is about
3 Mb.  If you were embedding Python with that library, you would not
be including _all_ of that 3 Mb: if you only used PyIntegerObjects,
then you would probably not link with the longobject.o, complexobject.o,
etc. (except on misbehaving systems like AIX).  But if you linked
with a dynamic library (libpython1.5.so), then the entire 3 Mb would
be linked.

Yes, there are reasons to want shared objects, but there are also
good reasons to use static libraries.

  -Arcege





More information about the Python-list mailing list