[Cython] Transformation of pxds

[Stefan Behnel]

Romain Guillebert, 26.07.2011 04:10:
> I can now compile pxd files, but I have encountered something rather
> strange : AnalyseExpressionsTransform turns :
>
> cimport foo
>
> def test():
>      foo.printf()
>
> into :
>
> cimport foo
>
> def test():
>      printf()

This makes sense from the POV of C, which has a flat namespace. It is true 
that this doesn't make much sense for the Python backend. Specifically, we 
do not want to flatten the .pxd namespace here, because the attribute name 
may already exist in the module namespace. Only the qualified name gives us 
proper and safe Python code.


> It is due to the method analyse_as_cimported_attribute of AttributeNode
> in the file Cython/Compiler/ExprNodes.py
>
> Is this useful (since I don't think it has anything to do with
> expression analysis) and do you have an idea on how I can solve this (my
> first idea is : extend the class to disable the effect of this method
> but it's more a hack than anything else) ?

Well, the current implementation is already a huge hack, see 
mutate_into_name_node(). The proper fix we envisioned for cases like this 
is to globally refactor the analyse_types() methods into methods that 
return self, or any other node that they deem more appropriate. The caller 
would then put the returned value in the place of the original node. This 
approach would allow analyse_as_cimported_attribute() to simply instantiate 
and return a new NameNode, instead of having to changing the type of itself 
locally.

However, so far, no-one has done anything to get this refactoring done, 
likely because it's a lot of rather boring work.

Regardless of this refactoring, I think it might be best to explicitly 
implement this method in a backend specific way. When targeting C, it 
should flatten the attribute access. When targeting Python, it should still 
determine the entry (and thus the type of the attribute) but should not 
build a NameNode.

I assume the problem here is that the method does not actually know which 
backend it is targeting, right? The "env" parameter (i.e. the scope) won't 
know that, and I'm not sure it should know that. My suggestion is to let 
the module scope of the .pxd know that it's being read into (or as) a flat 
or prefixed namespace, and to propagate the information from there into the 
Entry objects it describes. Then the Entry of the attribute would know if 
it needs a namespace or not, and the analysis method could get its 
information directly from there.

Does that make sense?

Stefan