2010/12/14 Vitja Makarov <vitja.maka...@gmail.com>: > 2010/12/14 Stefan Behnel <stefan...@behnel.de>: >> Vitja Makarov, 14.12.2010 15:49: >>> 2010/12/14 Stefan Behnel<stefan...@behnel.de>: >>>> Vitja Makarov, 14.12.2010 14:45: >>>>> 2010/12/14 Stefan Behnel: >>>>>> Stefan Behnel, 13.12.2010 06:37: >>>>>>> Vitja Makarov, 12.12.2010 20:23: >>>>>>>> What do you think about GeneratorWrapperNode? >>>>>>> >>>>>>> It seems ok. I'll give it a deeper look ASAP. >>>>>> >>>>>> Actually, after looking through it, I think it's an ugly hack. It tries >>>>>> to >>>>>> hide the fact that the DefNode does the wrong thing for the two faces of >>>>>> generators, and that the current implementation does not build a separate >>>>>> node at transform time that does the right thing instead. IMHO, two nodes >>>>>> are needed. A CFuncDefNode (or a subtype) that writes out the generator C >>>>>> function with the right signature and the original body, and the original >>>>>> DefNode (with the original signature) that has its body replaced by the >>>>>> necessary generator setup code. That's basically why the original CEP >>>>>> proposed to split the DefNode implementation *before* going for >>>>>> generators. >>>>>> Would have made this easier. >>>>> >>>>> Are you sure that CFuncDefNode for generator body is a good idea? >>>>> >>>>> Nested function and classes, lambda, generators are not supported >>>>> inside CFuncDefNode. >>>> >>>> Hmm, right, that's a missing feature that could become a problem. >>>> >>>> Second try. Create a new subtype of DefNode that nails the signature to >>>> METH_O and additionally implements all the generator specific stuff, >>>> potentially through sensible hooks in DefNode's code generation. >>>> >>> >>> What is the best place to create node for generator body? >> >> "Create" as in "implement"? In Nodes.py. >> >> "Create" as in "instantiate"? Depends. The canonical answer is "in a >> transform", but sometimes it's easier to do it inside of a node. If the >> latter, the canonical answer would become analyse_types(). If that's too >> late, well, back to a transform. :) >> > > I think analyse_types() should be ok, and it wouldn't break things >
Why did you reverted decorators stuff? https://github.com/vitek/cython/commit/e0d366d9409680849e6f429992ac9724e2ad1016 -- vitja. _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
