Extension modules and common routines in Python/C API

Stefan Behnel stefan_ml at behnel.de
Mon Jun 28 03:30:18 EDT 2010


ty ty, 28.06.2010 08:16:
> I'm writing wrapper for C library. This library consist of several
> parts. And i want split my extension package into different extension
> modules. I think, this is the right way ;-)

Depends. If it's somewhat large or deals with sufficiently distinct 
functionality, it might be worth doing.


> But, there are some common
> parts that exist in extension package, get_library_version, Error, and
> so on. I've decided to create additional module, named core, where these
> routines and variables are defined.

Is that supposed to be used by Python code or internally by your modules? 
If it's the latter, I'd just write a plain C module and link it into each 
of the extension modules that use it. Otherwise, a common utility module 
might be ok, but I don't know anything about your real code that would 
suggest either way. You may also consider taking both approaches, i.e. 
write a linked-in module and a public Python wrapper around it.


> And when get_library_version, for
> example, is used by programmer, Error, in opposite, is used by routines
> in another modules. As i mentioned in ( above mail), i use create_error
> for adding new exception class with neccessary fields. Now i call
> create_error in initcore function, which initialize core module. But, if
> i don't import package.core, and only import package.module, when
> package.module.function fails , python's runtime throws error

Obviously. Just make sure you always import your core module first. If it 
defines something as basic as the main error class (assuming that's what 
you meant with "Error"), I'd make that the very first thing in the init 
function.

You might also want to take a look at Cython. It's a Python dialect that 
makes writing extension modules easy, so if you have a lot of C code to 
wrap, it'll help you get it done substantially faster than in plain C code.

Stefan




More information about the Python-list mailing list