Stefan Behnel <stefan...@...> writes: > 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) > > 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.
Disclaimers: * Sorry if I misunderstood your argument. * I'm completely ignorant about the inner workings of Cython, * and of C, * and of unicode vs char*... 8-) In Python, however, decorators can be classes, and thus have any amount of internal state and trickery -- including, I'd guess, creating and storing references. See the "memoization" example here: http://avinashv.net/2008/04/python-decorators-syntactic-sugar/ Best regards, Jon Olav _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
