Need more comments from scientific community on python-dev

Sasha ndarray at
Wed Nov 1 09:27:48 CST 2006

On 10/31/06, Travis Oliphant <oliphant at> wrote:
> No, it's not that simple.  We have a headache whenever we want to do
> something like I just did and separate out the concepts of what makes a
> Python Object a Python object.  Now, we don't just modify a simple
> C-structure (PyArray_Descr *), we have to modify a "meta-type" or a
> altered dictionary and get that change put in to ctypes.

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.

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

More information about the Numpy-discussion mailing list