[PYTHON MATRIX-SIG] [comp.lang.python] Proposal for sharing C interfaces between extension modules

[Jim Fulton, U.S. Geological Survey]

The following message was posted on the Python list.  One of the
driving reasons for this proposal is to simplify the configuration of
the matrix object implementation and the many extension modules that
will use it.  

My idea is that the matrix object can be included in a module and that
the C interface to the matrix object type can be exported as a
collection of CObjects or through a single CObject that is an array
or struct (or other data structure) of C function pointers.  Then
extension modules that want to use the C interface to the matrix
object can import the matrix module and use PyObject_GetAttrString to
get access to the C interface.

In this way, the matrix object need not be munged into the standard
source tree.

-- Jim

------- Forwarded Message

From: jfulton@disqvarsa.er.usgs.GOV (Jim Fulton )
Newsgroups: comp.lang.python
Subject: Proposal for sharing C interfaces between extension modules
Date: 12 Dec 1995 19:36:04 GMT
Organization: U.S. Geological Survey
NNTP-Posting-Host: disqvarsa.er.usgs.gov


Problem: It is sometimes the case that an extension module needs to
export a C interface to other extension modules. This is especially
true for modules that define useful built-in types.

If modules are dynamically linked, sharing C interfaces between
modules can get someone complicated, because the extension modules
need to get linked together and get linked with Python.  How this is
done can vary significantly from system to system.

Python already provides a dynamic linking facility, via import.  An
extension module can import other modules, including other extension
modules.  So, for example, a Matrix module could import a complex
number module and use PyObject_GetAttrString to get any objects
(classes, functions, etc) exported by the complex module.  This
mechanism is nice because it doesn't depend in any way how the module
being imported was linked.  Python handles the linking for you.

Unfortunately, this currently only works with Python objects exported
by a module.

(Fortunately, if only a Python interface to a module is needed, this
 mechanism allows an extension module to "link" to another module
 regardless of whether the other module is a Python module or an
 extension module. Cool. :)

I propose adding a very small new type to the core language, called
CObject, that is a Python wrapper for C objects.  On my system, this
new type adds a total of 204 bytes to the text portion of the
interpreter. :-)

If an extension module wishes to export a C object (such as a C
function, or an array of C functions) to other extension modules, the
extension module would use the function CObject_FromVoidPtr to create
a Python object that wraps a pointer to the C object.  The module
would then insert this object in the module's dictionary during module
initialization.

Here is the declaration for CObject_FromVoidPtr:

  /* Create a CObject from a pointer to a C object and an optional
     destrutor function.  If the second argument is non-null, then
     it will be called with the first argument if and when the CObject
     is destroyed.  
  */
  extern PyObject *
  CObject_FromVoidPtr Py_PROTO((void *cobj, void (*destruct)(void*)));

An extension module that wishes to use a C object exported by another
extension module, would:

   - Import the other module, 
   - Use PyObject_GetAttrString to get the CObject, using a published
     name, and
   - Use CObject_AsVoidPtr to obtain a pointer to the C object,

Here is the declaration for CObject_AsVoidPtr:

/* Retrieve a pointer to a C object from a CObject. */
extern void *
CObject_AsVoidPtr Py_PROTO((PyObject *));

Of course, CObjects exported by a module can be accessed from Python,
but they provide no useful behavior that can be accessed directly from
Python scripts.  They can be assigned to Python variables and passed
to extension functions or extension type methods.

This small extension to the language should significantly ease the
configuration of modules that need or want to interface with each
other via C.
--
-- Jim Fulton      jfulton@usgs.gov          (703) 648-5622
                   U.S. Geological Survey, Reston VA  22092 
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.

------- End of Forwarded Message

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================