On May 17, 2008, at 12:36 PM, Dag Sverre Seljebotn wrote:
>>> If it helps with the funny feeling, the string is only parsed
>>> directly in
>>> the constructor for TreeFragment (and it accepts a more directly
>>> created
>>> node structure too). So the string disappears from the story after
>>> module
>>> load time; from there it is only tree node manipulation (the
>>> TreeFragment
>>> acts like a template which is cloned while substituting nodes on the
>>> clone). So there's nothing that requires the string but notational
>>> convenience.
>>
>> Yes--the TreeFragment idea makes things much cleaner. Are EXPR et al.
>> special words then?
>
> No -- they are inserted into the trees as a regular NameNode (so any
> name resolving done by the parser will happen to them -- if this bites
> us, it is a case for refactoring such functionality to a post-parse
> transform; although in practice we'll just use another name :-) ).
>
> However, since they just sit there in the tree, they can be
> replaced by
> much more complex nodes.
>
> Hmm.. that's something! I should probably "replace the enclosing
> ExprStatNode instead, if any". Thanks for putting me on track of a
> bug :-)
>
> The context of the string is a module-level pyx-file without any
> imports
> but __builtin__. This can be altered though. (For instance, no
> file-lookup happens in the case of "cimport" or "include" in such a
> string, instead an exception is raised.)
>
> If this simple use of NameNode is not sufficient, one can extend the
> parser to parse special nodes if in a special mode ("${BLOCK}"
> parses to
> "CustomNode(contenst="BLOCK")", however I don't think that will be
> necesarry.
As long as the fragments are replaced all at once (rather than
sequentially) then it should work just fine. Otherwise you could have
(using your example again) the block EXPR containing a NameNode VAR,
which would be bad.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
