[Numpy-discussion] swig svn commits
Sat Mar 24 20:15:34 CDT 2007
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@example.com> 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.
>> 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:
>>> this is regarding the svn commit by wfspotz.
>>> Author: firstname.lastname@example.org
>>> Date: 2007-03-23 13:04:37 -0500 (Fri, 23 Mar 2007)
>>> New Revision: 3593
>>> Added typecheck typemaps to INPLACE_ARRAY typemap suites
>>> Hi wfspotz,
>>> I was just wondering if you consider checking for "native byte
>>> 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
>>> Numpy-discussion mailing list
>> ** Bill Spotz **
>> ** Sandia National Laboratories Voice: (505)845-0170 **
>> ** P.O. Box 5800 Fax: (505)284-5451 **
>> ** Albuquerque, NM 87185-0370 Email: email@example.com **
>> Numpy-discussion mailing list
> Numpy-discussion mailing list
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-5451 **
** Albuquerque, NM 87185-0370 Email: firstname.lastname@example.org **
More information about the Numpy-discussion