Need more comments from scientific community on python-dev
Sasha
ndarray at mac.com
Wed Nov 1 10:27:48 EST 2006
On 10/31/06, Travis Oliphant <oliphant at ee.byu.edu> 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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
More information about the NumPy-Discussion
mailing list