[Python-Dev] framer tool
Jeremy Hylton
jeremy@alum.mit.edu
Mon, 5 Aug 2002 14:14:07 -0400
>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:
[From a checkin that I made recently of Tools/framer]
>>> framer is a tool to generate boilerplate code for C extension
>>> types.
Jack> how does framer relate to modulator? Is it a replacement?
Jack> Should modulator be adapted to framer? (And, if so, who's
Jack> going to do it? :-)
Framer could be a replacement for modulator. The original impetus for
framer came from Jim Fulton, who suggested that modulator be updated
so that it could be used for C extension types.
I thought that Zope-style interfaces would be a nice way to specify
the signatures of the extension module and types. Since modulator
didn't handle the specifications or the new 2.2/2.3 features, I didn't
really look at it.
Should I try to make framer a modulator replacement? I've got some
time to work on it, but checked in the current progress in hopes of
finding more help.
SM> How does framer relate to Pyrex?
Pyrex is a tool to generate a complete C module from a variant of
Python source. Framer is a tool to generate just the boilerplate --
the frame. Framer is intended to support people who are going to
maintain a C extension by hand. The code it generates is easy to read
and edit. I wouldn't want to read the Pyrex-generated C code.
Pyrex is intended for converting existing Python code to C, for
performance. (I think.) Framer is intended for C programmers who
don't want to type all the boilerplate for an extension. In some
ways, it's closer to SWIG than to Pyrex.
I think there is a common subset of functionality to Pyrex, SWIG, and
Framer -- namely generating the basic wrapper code to make C code
callable from Python. It might be worthwhile to share that code among
the projects; Greg certainly seems to have covered a lot of ground
handling __methods__ with Pyrex.
Jeremy