Hi,
Simon Anders, 03.12.2009 20:52:
> typemaps sound very useful to me. However, what always bothers me in
> SWIG's implementation is that the map is associated with a C type. So, if
> you have, say, two 'char *' arguments in a function to be wrapped that need
> to be converted differently you need some strange argument name pattern
> matching to tell SWIG which conversion to use where.
>
> In Cython, we are free to define new types. What about an extension to the
> 'ctypedef' syntax similar to the property syntax?
>
> As an example, let's say that in our C code, "char *" is sometimes a
> unicode string and sometimes an array of bytes. Then we might introduce
>
> ctypedef char* unicode with:
> cdef char* __py2c__( str a ):
> ...
> cdef str __c2py__( char* ):
> ...
>
> ctypedef char * byte_array with:
> cdef char* __py2c__( list a ):
> ...
> cdef list __c2py__( char * ):
> ...
Makes sense to me. It would also allow you to define more than one mapper
'method', i.e. you could have
ctypedef char * byte_array:
cdef char* __py2c__( list a ):
...
cdef char* __py2c__( bytes a ):
...
cdef char* __py2c__( unsigned char* a ):
...
cdef char* __py2c__( unicode a ):
...
etc. (note that I stripped the 'with' at the end of the initial line, I
think it's not needed).
> Of course, if a type only appears as parameter type or only as return
> type, one needs to declare only one of __py2c__ or __c2py__ (similar to
> SWIG's 'in' and 'out' typemaps).
That would be fine, sure. Although we might want to provide a way to say
"please disallow any coercion from type X".
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
