Hi, Dag Sverre Seljebotn wrote: > - It took me some minutes to understand the concept. I definitely think > another name (as you suggest) would help a lot and perhaps make the > concept immediately graspable. How about "LetNode" for > EvalWithTempExprNode? (I don't have a good suggestion for the reference > node, "LetRefNode" or similar in lack of something better).
Sounds like what it does, yes. "EvalWithTempExprNode" was the third name already, as the underlying concept changed with trial-and-error. > - It seems to mostly be "TempsBlockNode" except with a different > (better?) API and designed to work as an ExprNode. Is it redundant with > both? It's a bit hackish in that it sets the result_code from outside. It also only handles a single expression, but I actually think that this makes it cleaner. You can easily chain it. It should also be used in a more fine-granular way than the TempsBlockNode, to allow early temp deallocation. There's a difference if you don't have an expression to wrap and only want to allocate temps. It doesn't handle that case. Although you could argue that you could always use an expression that returns the type specific init value (NULL, 0, None, ...). BTW, I'm not 100% sure yet that it works in all places where you might want to put it. But if it fails somewhere, that should not be too hard to fix. It will not fix the with statement for you, though. I start to think that a dedicated node might still be the best way to make this work. > I.e. "LetNode" could perhaps implement both interfaces and play > the role both as ExprNode and StatNode. (No hurry though!) You should be able to wrap the node in an ExprStatNode, no need to implement two interfaces here (although it might simplify things). Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
