dynamically loaded libraries
robert.kern at gmail.com
Mon May 29 07:33:39 CEST 2006
> I have a question about how dynamically loaded C++ modules work, which
> I will phrase as a hypothetical scenario involving the Numeric module.
> Please understand that I don't really care about Numeric per se, it's
> just a useful example of a module that defines a generally useful data
> Let's say I want to create a C++ Python extension module that has
> methods accepting the Numeric array type as input, and also create
> these arrays as output.
> In order to make this work, do I have to statically link against the
> Numeric source, or do I only have to include the headers, under the
> assumption (??) that the Numeric functionality will be available
> because the Python executable has dynamically loaded it?
Here's how Numeric/numarray/numpy do it (I'll discuss numpy since it is the
currently developed one):
Pointers to each of the API items that we want to export, types and functions
mostly, are packed into a void** array, PyArray_API. A common header file is
used by the numpy extension module that provides the API (multiarraymodule.so)
and each of the modules that use the API. We use #ifdefs to determine whether to
use real prototypes (for multiarray) or #defines that index into PyArray_API and
cast the function pointer there to the appopriate prototype (for everybody else).
In initmultiarray(), we actually pack PyArray_API with the appropriate pointers
and create a PyCObject that points to the beginning of the array. The CObject is
assigned to multiarray._ARRAY_API . We define a function import_array() for the
API-users that will import multiarray, get the object _ARRAY_API and assign
pointer to the beginning of the array to void **PyArray_API. import_array() is
supposed to be called in the initialization function of the other extension
modules. That will make sure that multiarray is imported and the function
pointers are available for dereferencing.
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the Python-list