Need more comments from scientific community on python-dev

Travis Oliphant oliphant.travis at ieee.org
Wed Nov 1 09:57:10 CST 2006


Alexander Belopolsky wrote:
> On 10/31/06, Travis Oliphant <oliphant at ee.byu.edu> 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.
>   

And I think I'm beginning to understand why some people are resistant to 
what I'm saying.   I have no problem converting from ctypes types to the 
underlying PyArray_Descr structure.  I don't necessarily want that to be 
the only way to describe new types but I sure don't mind people using 
that approach.

I suspect it's the concern about "how to describe data-formats on the 
Python level" that have people concerned.  

> 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?
That is correct. 

>  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.
Thanks for this suggestion.  You could very probably be right.
>   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.
>
>   
It would actually be "easier" for NumPy to understand ctypes syntax if 
something like a data-type object were.  As it is, the converter to a 
PyArray_Descr structure will probably have to check the tp_name of the 
ctypes.  Maybe this will help with the PEP to describe the difficulty of 
using ctypes constructs inside of other programs.

And it may be a good idea to also have a get_ctype method or some-such 
on the ctypes attribute so that  one could get a "ctypes description" 
from the NumPy data-type.

-Travis


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