[PYTHON MATRIX-SIG] A ramble on ofunc's and omath

Jim Fulton, U.S. Geological Survey jfulton@usgs.gov
Fri, 15 Dec 1995 09:40:16 -0500


On Dec 15,  9:05am, Hinsen Konrad wrote:
> Subject: Re: [PYTHON MATRIX-SIG] A ramble on ofunc's and omath
>
>    > That is certainly preferable. However, I am not sure whether it
>    > is possible in all cases with the current implementation. Clearly
>    > there is not much provision for C modules that depend on each other.
>    > Your proposed CObjects solve one problem, but there may be more.
>
>    There may be, but I haven't though of any yet.  If you come up with any,
I'd be
>    happy to try to come up with a solution to them too. :-]
>
> It seems that you can do everything necessary with these CObjects. After
> all, you can make all non-static variables and functions known in this
> way,

Actually, with CObjects, all of the exported C objects can be static.  So
essentially, the only non-static variable in a module is the module
initialization function.  This is a plus when the module is statically linked,
because you don't have to worry about global name colisions.  You get the
benefits of Python's namespace mechanisms even for your C code. :-)

> and then you have published everything that other statically
> linked C modules have access to.
>
> A potential problem is that another module can do whatever it wants
> with the CObjects, including something wrong (like calling a variable).

This is a problem with C in general. Of course ...

> This can be avoided (except for intentional misuse) by providing
> a header file that decribes the public features of a module.

Absolutely.

> One could produce a tool (in Python, of course!) that produces such
> a header file with the prototypes of the original module code.
> It could be made so easy to use that except for an additional import
> call at the beginning, another module could use all functions and
> variables exactly as if they were statically linked. And then one
> could pack the whole interface for a module into a single CObject,
> which helps keeping a module's name space clean.

Yup, there are plenty of opportunities to build on and improve the basic
mechanism.  Alot of this depends on how complex the C interface being exported
is.

Jim


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

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