On Apr 3, 2010, at 5:24 AM, Stefan Behnel wrote: > Haoyu Bai, 03.04.2010 14:15: >> On Sat, Apr 3, 2010 at 6:50 PM, Stefan Behnel<[email protected]> >> wrote: >>> Haoyu Bai, 03.04.2010 09:18: >>>> Thinking about how to implement Cython decorators (@cclass, @cfunc >>>> etc.) for pure Python mode, I come up with an idea of "compile-time >>>> decorator". Basically, we want these decorators to have effect >>>> during >>>> compile time, rather than normal Python decorator that is called in >>>> runtime. So, to implement @cfunc, we can actually implement a >>>> function >>>> cfunc(node), which inputs a DefNode and transform it to a >>>> CFuncDefNode, then put the function into the compile-time scope. >>> >>> -1, we shouldn't expose Cython compiler internals to the language >>> level. >>> >>> It's better to use a transform that intercepts on certain >>> decorators. >> >> By implement @cfunc as a function, I'm not mean to implement it *in >> Cython*, it is still a part of the Cython compiler, as the >> transforms. >> And the main motivation is not to expose Cython internal to the >> users, >> but to have a flexible mechanism to support the various decorators - >> Cython directives, @cclass @cfunc, and even some Python builtin >> decorator (@classmethod, @staticmethod and @property). >> >> These are decorators need to be executed in compile time. Currently, >> the code to deal with these decorators are scattered in many places, >> some in transforms, some in nodes. It would be better to have a >> unified mechanism to deal with all of these decorators. That's what I >> proposed. >> >> Indeed, the node classes do not provide an API so we should not >> expose >> them to end-user. But there is nothing to prevent us to write >> compile-time function to process them inside Cython (and decorator is >> just functions). > > In that case, there is nothing to gain from making them "compile time > evaluated functions", because the implementation itself would still be > inside of the compiler. So the decorator would still just be a name > for > something that is triggered inside of the compiler, which may be a > code > block, a function, a method or a whole transformation class. > > While I do not doubt that there is potential for a code cleanup, the > main > reason why the "decorators are scattered in many places" is that their > implementation requires code to be executed during different compiler > stages. This cannot be helped by stuffing everything into a single > function.
Also, many (most?) directives (e.g. boundscheck, cdivision, infer_types) aren't best expressed as node transformations, rather they simply affect the behavior of the contained code. I would certainly imagine that @cfunc, @cclass, (and others) will be implemented a visitor that in turn calls such transforming functions. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
