Creating a "package" using C extensions?

[Steven Majewski]

On Sun, 9 Dec 2001, Courageous wrote:

> This is liveable, but somewhat painful for me. Let me tell
> you why. I am currently translating the back end of a system
> originally written in Python to a hybridized C++/Python
> implementation with a C++ core. The heart of the system has
> a very high invocation frequency, so it makes sense to put
> that into C++. However, I need to make the prior interface
> to the Python programmer the same as it was before. So what
> I am doing is, for every module in the prior package, creating
> a C++ equivalent.
>
> That's a lot of .dlls, if you know what I mean.
>
> Perhaps I'll break down and write a makefile. Doing a couple
> dozen .dlls in VC 6.0 is a bit of a pain.
>
> It's too bad there's not a way to create a package-level .dll
> which responds to Python in such a way as to offer up its
> internal modules, but all from within a single .dll. That would
> be cool.

 Before Jack fixed up the current Carbon modules for MacOSX Python,
I had problems building them as separate shared libraries because
they had so many shared routines between them ( for example, a lot
of other toolbox modules use Mac Resources, so they use routines
in Resmodule, but directly, not by importing the module. ).
 My temporary solution was to build ALL of the Carbon toolbox modules
into a single Carbonmodule.so .


Using this macro:

#define ADD_MODULE(x)     if (-1 == \
    PyModule_AddObject( m, (x), PyImport_ImportModule((x))))  return NULL

for each submodule I had (for an example, for the Win module) the lines:

   initWin()
   ADD_MODULE("Win")


This put everything into a single shared library.

You could then do, for example:

	from Carbon import Win

or, once you have done an initial:

	import Carbon

all of the submodules are added to sys.modules, so you could also do:

	import Win

This was intentional, so that once Carbon had been imported,
(perhaps in site.py )  old scripts that used the latter import
would still work.

I don't think it followed the package semantics entirely --
I don't think you could do:

	import Carbon.Win


(I'm not entirely sure -- since Jack came up with a better scheme
 I don't have that code nearby any longer. It's been archived. )

But if you want to avoid having a whole big bunch of DLL, you
could do something similar.


-- Steve Majewski