On Dec 3, 2009, at 11:41 PM, Jon Olav Vik wrote: > 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/
The cython decorators aren't really implemented as decorators, they're compiler directives. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
