[Numpy-discussion] swig svn commits

[Bill Spotz]

OK.  So if I understand this correctly, PyArray_EquivTypenums() can't  
do native byte order checking.  But I'm assuming PyArray_EquivTypes()  
could.  Unfortunately, the numpy.i typemaps are based on the  
enumerated typenums, not PyArray_Descr objects.

There are a couple of other places where the more sophisticated  
PyArray_Descr approach would be beneficial, such as for bools and  
complex types (as well as a bunch of others, I'm assuming), so I'm  
open to it, but it would take some work.

On Mar 24, 2007, at 12:39 PM, Sebastian Haase wrote:

> On 3/24/07, Bill Spotz <wfspotz at sandia.gov> wrote:
>> No, I don't consider native byte order.  What was your solution?
>>
> I think there is only one solution:
> If somebody requests INPLACE handling but provides data of
> wrong byteorder,  I have to throw an exception -- in SWIG terms, the
> typecheck returns False (if I remember right).
>
> For me this is just a "last-line of defence"  - meaning that I have
> most of my functions wrapped by another level of python "convenience"
> functions, and those take care of type and byte-order issues
> beforehand as needed.
>
> -Sebastian
>
>
>> The typecheck typemap is so that swig can perform isolated type
>> checking when it is creating dispatch code for overloaded functions.
>> The typechecks I added for INPLACE arrays require that the argument
>> be a numpy array and that PyArray_EquivTypenums() return true for the
>> provided and requested types.
>>
>> On Mar 23, 2007, at 3:03 PM, Sebastian Haase wrote:
>>
>>> Hi,
>>> this is regarding the svn commit by wfspotz.
>>>
>>> Author: wfspotz at sandia.gov
>>> Date: 2007-03-23 13:04:37 -0500 (Fri, 23 Mar 2007)
>>> New Revision: 3593
>>>
>>> Modified:
>>>   trunk/numpy/doc/swig/numpy.i
>>> Log:
>>> Added typecheck typemaps to INPLACE_ARRAY typemap suites
>>>
>>> Hi wfspotz,
>>> I was just wondering if you consider checking for "native byte  
>>> order"
>>> as part of your inplace-typemap.
>>> I found that to be a problem in my SWIG type maps
>>> that I hi-jacked / boiled down  from the older numpy swig files.
>>> (They are mostly for 3D image data, only for a small number of  
>>> types)
>>>
>>> -Sebastian
>>> _______________________________________________
>>> Numpy-discussion mailing list
>>> Numpy-discussion at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
>> ** Bill Spotz                                              **
>> ** Sandia National Laboratories  Voice: (505)845-0170      **
>> ** P.O. Box 5800                 Fax:   (505)284-5451      **
>> ** Albuquerque, NM 87185-0370    Email: wfspotz at sandia.gov **
>>
>>
>>
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion at scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-5451      **
** Albuquerque, NM 87185-0370    Email: wfspotz at sandia.gov **