Barking up the wrong tree with extension types and modules?

[Steve Juranich]

We have a large suite of "legacy" tools (based on stand-alone executables
and shell scripts) that we would like to integrate into a suite of Python
modules. I'm having a little trouble getting my head around how the best
way to implement the whole thing, though.

Here's (roughly) the situation:

We have TypeA which is used *everywhere* in the tools. I have completed a
wrapper for TypeA and can now create Python versions of the TypeA object.
I'd now like to write wrappers for ToolSet1 and ToolSet2 which make
extensive use of TypeA.

I'd also like the resulting C code to be maintainable. I know that I can
write bighonkingmodule.c that incorporates the wrappers for TypeA,
ToolSet1, and ToolSet2, but this could easily lead to a maintenance
nightmare. I would like to have TypeA_wrap.c, ToolSet1_wrap.c and
ToolSet2_wrap.c that would generate 3 separate modules:

TypeA.so : The compatibility layer for the TypeA object.
ToolSet1.so : Compatibility layer for tools in ToolSet1
(This ingests and generates TypeA objects).
ToolSet2.so : Compatibility layer for tools in ToolSet2
(This also ingests and generates TypeA objects).

I also know that I could put a definition for TypeA in both ToolSet1 and
ToolSet2, but then (as far as I understand), outputs from ToolSet1 wouldn't
be readily available for processing in ToolSet2 because each module would
have its own idea about what a TypeA actually is.

Basically, the type of package structure I want is something like:

OurTools/
__init__.py
TypeA.so
ToolSet1.so
ToolSet2.so
ExtensionSet1.py
...

Has anybody tackled anything like this before? Are there any examples that
I could look at?

One way I've thought about doing it is kind of how I understand the
interpreter to do it which would be something like:

1. Provide libOurToolsPython.so and OurToolsPython.h that would define
common interfaces that would need to be available to all of the ToolSet
wrappers.
2. When I build ToolSet1_wrap.c, I'd need to include OurToolsPython.h and
link against libOurToolsPythyon.so

Am I thinking about this the right way, or am I *completely* twisted around
the axle here (which is kind of how I feel)?

Thanks in advance for any comments, corrections, and directions.

--
Steve Juranich
Tucson, AZ
USA