[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.