Awesome! Thanks Gerard. This certainly sounds like the way to do it. I'll take a closer look tomorrow. Regards, Todd On Tue, 2004-06-29 at 17:32, gerard.vermeulen@grenoble.cnrs.fr wrote:
On 29 Jun 2004 15:09:43 -0400, Todd Miller wrote
On Tue, 2004-06-29 at 13:44, Gerard Vermeulen wrote:
The PEP is attached. It is formatted using the docutils package which can be used to generate HTML or PDF. Comments and corrections would be appreciated.
PyQwt is a Python extension which can be conditionally compiled against Numeric and/or numarray (both, one of them or none).
Well that's cool! I'll have to keep the PyQwt guys in mind as potential first users.
Your PEP excludes importing of Numeric and numarray in the same C-extension.
This is true but I don't understand your solution so I'll blather on below.
All you need to do is to hide the macros PyArray_Present(), PyArray_isArray() and import_array() into a few functions with numarray specific names, so that the following becomes possible:
#include
/* defines the functions (no macros) int Numeric_Present(); int Numeric_isArray(); void import_numeric(); to hide the Numeric C-API stuff in a small Numeric/meta.c file. */ #include /* defines the functions (no macros) int numarray_Present(); int numarray_isArray(); void import_numarray(); to hide the numarray C-API stuff in a small numarray/meta.c file. */ I may have come up with the wrong scheme for the Present() and isArray(). With my scheme, they *have* to be macros because the API functions are unsafe: when numarray or Numeric is not present, the API function table pointers are NULL so calling through them results in either a fatal error or a segfault.
The macros can be hidden from the module file scope by wrapping them in a function (see attached demo)
There is an additional problem that the "same functions" need to be called through different API pointers depending on whether numarray or Numeric is being supported. Redefinition of typedefs and enumerations
(or perhaps conditional compilation short-circuited re-definitions) may also present a problem with compiling (or worse, running).
Tested and works.
I certainly like the idea of supporting both in the same extension module, but don't see how to get there, other than with separate compilation units. With seperate .c files, I'm not aware of a problem other than lots of global symbols. I haven't demoed that yet so I am interested if someone has made it work.
Yes, you cannot mix the numarray API and Numeric API in the same .c file, but nevertheless you can hide the macros in small functions so that the macros don't pollute.
Here you have a litte extension module 'pep' which tries to import Numeric and numarray. It has a method 'whatsThere' that prints the names of the Numerical/numarray extension modules it has imported.
It has also a method 'whatsThis' that prints if an object is a Numeric array, a numarray array or something else:
Python 2.3.3 (#2, Feb 17 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import pep pep.whatsThere() Numeric! Numarray! import Numeric a = Numeric.arange(10) pep.whatsThis(a) Numeric array import numarray a = numarray.arange(10) pep.whatsThis(a) Numarray array a = 10 pep.whatsThis(a) Something else
The MANIFEST reads: pepmodule.c setup.py Numeric/meta.c Numeric/meta.h numarray/meta.c numarray/meta.h
My initial idea was to add the meta.* files to the Numeric/numarray include files, but I did not try yet to solve the problem of the PyArray_API PY_ARRAY_UNIQUE_SYMBOL defines in the same way (I am sure it can be done.
Regards -- Gerard --