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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Reply via email to