[Numpy-discussion] Numarray header PEP

Todd Miller jmiller at stsci.edu
Tue Jun 29 12:10:20 CDT 2004


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 <Numeric/meta.h>
> /* 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 <numarray/meta.h>
> /* 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.

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).  

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.

Thanks very much for commenting on the PEP.

Regards,
Todd

> PyObject *
> some_array_returning_function(PyObject *m, PyObject *args)
> {
>     int param;
>     PyObject *result;
>     
>     if (!PyArg_ParseTuple(args, "i", &param))
> 	return NULL;
>     
>     if (Numeric_Present()) {
> 	result = numeric_returning_function(param);
>     } else if (Numarray_Present()) {
> 	result = numarray_returning_function(param);
>     } else {
> 	result = list_returning_function(param);
>     }
>     return result;
> }
> 
> PyObject *
> some_array_accepting_function(PyObject *m, PyObject *args)
> {
>     PyObject *sequence, *result;
>     
>     if (!PyArg_ParseTuple(args, "O", &sequence))
> 	return NULL;
>     
>     if (Numeric_isArray(sequence)) {
> 	result = numeric_input_function(sequence);
>     } else if (Numarray_isArray(sequence)) {
> 	result = numarray_input_function(sequence);
>     } else {
> 	result = sequence_input_function(sequence);
>     }
>     return result;
> }
> 
> /*
>   the code for the numeric_whatever_functions and for the
>   numarray_whatever_functions should be source files.
>  */
> 
> static void
> initfoo(void)
> {
>     PyObject *m = Py_InitModule3(
> 	"foo",
> 	_foo_functions,
> 	_foo__doc__);
>     if (m == NULL) return;
>     import_numeric();
>     import_numarray();
> }       
> 
> Regards -- Gerard
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4576





More information about the Numpy-discussion mailing list