On Dec 3, 2009, at 7:48 AM, Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: >> Hi Lisandro, >> >> that idea isn't that wild at all. It also occurred to me while I was >> thinking about the string encoding stuff. However, there are certain >> drawbacks to this that do not make it easily suitable. >> >> Lisandro Dalcin, 03.12.2009 16:08: >> >>> cdef current_encoding = "latin-1" >>> >>> cdef unicode charp2unicode(char* p): >>> return p.decode(current_encoding) >>> >>> and (somehow) add a to mapping (new syntax likely required): >>> >>> C_2_Python['char*'] = charp2unicode >>> >> >> Seeing this in action makes me think that a decorator would fit >> nicely here: >> >> @cython.typemapper(default=True) >> cdef inline unicode charp2unicode(char* p): >> return p.decode(current_encoding) >> >> @cython.typemapper >> cdef inline bytes charp2unicode(char* p): >> return <bytes>p >> >> The compiler could then collect all such type mappers, make sure >> that only >> one of them is declared as the default mapper for an input type, >> and then >> just call them to do the type conversion between the types in a >> given context. >> >> Disadvantages: >> >> 1) The above works well for a global setup, but I'd expect there's >> a lot of >> code that requires different mappings depending on the context, at >> least >> for some types. (strings in lxml are certainly an example)
Perhaps we could come up with a way of using them in conjunction with a with statement, which could take care of locality. >> 2) The above will not work for the unicode->char* case, for >> example, as >> there is no way to store a Python reference outside of the converter >> function scope. So this is limited to simple coercions that do not >> create >> new Python references. >> > There's also the possibility of "overloading conversion operators", > similar to what you can do in C++. This binds it to type instead I like the idea of binding the conversion as part of the type declaration as well, though I don't have a ready syntax (though the above decorator is nice). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
