Re: [Numpy-discussion] Need more comments from scientific community on python-dev

[Alexander B. <ale...@gm...>]

On 10/31/06, Travis Oliphant <oli...@ee...> wrote:
...
> Please understand what I meant.  I meant putting effort into getting
> PyArray_DescrConverter to allow ctypes inputs and convert to the
> appropriate PyArray_Descr * structure.   I already understand ctypes
> objects.  I want the dtype() command to also understand them.
>

I think I am starting to understand. Forgive me for being slow.

Is it correct that you don't mind writing c_int * 10 instead of
dtype(('<i4', 10)) as long as the result does not have to be a
PyTypeObject at the C level? If this is the case, I would suggest to
merge ctypes syntax with your implementation.  This may help to make
the case for the python-dev crowd.  I believe very few people
understand the subtle problems in inheriting from PyTypeObject and
resist your proposal simply because they like c_int * 10  better than
dtype(('<i4', 10)).

There is no reason why ctypes should be implemented the way it is. It
is not necessary that type(c_int()) is c_int.  If a type with almost
the same properties gets into the core, ctypes developers may see an
advantage of simply inheriting from it and adding a factory __call__
method.  Meanwhile, users familiar with ctypes will not need to learn
yet another type specification syntax.