>>>>> "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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4