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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> 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@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: [EMAIL PROTECTED] ** >> >> >> >> _______________________________________________ >> Numpy-discussion mailing list >> Numpy-discussion@scipy.org >> http://projects.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@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: [EMAIL PROTECTED] ** _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
