>> 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.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
