[SciPy-dev] Changing return types in C API

[Sasha]

This probably belongs to numpy-discussion.  More below.

On 1/31/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
>  ...
> Could we change the API so that PyArrayObject * is used as the return
> type?
>

-1

Exposing the definition of the object structs is discouraged in python
code.  See for example a comment in intobject.h /*The type PyIntObject
is (unfortunately) exposed here so we can declare _Py_TrueStruct and
_Py_ZeroStruct in boolobject.h; don't use this. */ In numpy this is
necessary for performance reasons so that accessors can be implemented
as macros.  Making return types  PyArrayObject * will likely lead
people to use direct access to struct members instead of macros.

> On a similar note: the 'data' member of PyArrayObject's is a char *,
> where it really should be a void *. Being a void pointer would have
> the advantage of not needing the cast in cases like this:
>
> double *adata = (double)(a->data);

I think you meant (double*)

>
> It would also mean that accidentally dereferencing the pointer would
> be a compiler error: currently, a->data[0] is valid, but if a->data
> was a void *, it wouldn't be.
>

+1

Note, however that implicit cast is illegal in C++ and may generate
warnings on some compilers (I think gcc -pedantic would, but not
sure). Another problem with void* is that a->data + n will become
invalid, which is used in many places if I recall correctly.  
(a->data + n code is actually suboptimal when n is not constant
because most CPUs have special opcodes for pointer arithmetics that
compilers can generate if n is compile time constant)