Using Python As an Extensibility Library

[Jacob Smullyan]

On Fri, 7 Sep 2001 14:42:29 +0200, Alex Martelli <aleax at aleax.it> wrote:
>"kmalloc" <kmalloc at hotmail.com> wrote in message
>news:fa1faa6a.0109070256.2cc2d875 at posting.google.com...

>> 2) I have unsuccessfully tried to programmatically create a Python
>> class in an existing module dictionary. All I got was an access
>> violation...
>> Can anyone explain to me how to do that "the right way"?
>
>Defining Python *classes* in C isn't trivial -- I would
>suggest you look into C++ and Boost Python, or Fuller's
>ExtensionClass, or other such approaches, if you really
>need that (but Python 2.2, when it matures, will probably
>let you use a *type*, which you define in C, in a very
>close way to a class, so you may not really need it...).
>You can probably get away with a type, MUCH easier to
>define, and then if need be wrap it in a Python class so
>that client code can inherit/override/&c.

I have often read statements to the effect that it is
hard/impractical/ill-advised to write Python classes in C, and hence the
metaclass tricks in Boost and ExtensionClass, and the use of Python wrapper
classes around types.  Recently, however, I wanted to move a Python class to 
C, and, following the lead of Brent Burley's Python cookbook recipe
(http://aspn.activestate.com/ASPN/Python/Cookbook/Recipe/54352) and
Python/exceptions.c, it was quite simple to do, and appears to work fine.
I don't see what the obstacles or drawbacks are to this approach; am I
missing something?  The support code for making a class rather than a type
was perhaps ten or fifteen lines of boilerplate, largely like Burley's
recipe (except that if you want to have custom getattr/setattr/delattr
methods and the class methods aren't ready at class creation time, you need
to install them manually), so the difference in effort is really
insignificant.  Are there important performance considerations?

Jacob Smullyan
smulloni at smullyan.org