Romain Guillebert, 24.05.2011 22:36:
Sounds to me like you should attach the necessary information to the
symbol table entry when analysing he "external" declaration.
That's what I wanted to do that's why I asked how I could access the
external declaration node
Then you should have asked that in the first place.
There are declarator nodes for external declarations. You can traverse them
just like any other node. However, they get removed after declaration
analysis, so you need to have extracted all required information at that point.
Maybe you can just replace them by new nodes that implement the C access
for a specific external declaration?
We currently store a "cname", so adding something like a property name
or accessor information should fit your use case. We may want to
reserve a separate namespace for Python output related information,
though. Maybe something like "entry.pybackend.*"?
This would be a clean way to do it
Also, we considered having module level properties at some point.
That may fall into the same bucket.
Writing a transformation for that should be relatively straightforward.
Well, for the C code that Cython generates, it means that we first need to
implement our own module type in order to support properties at all...
What should happen for cimported declarations? Will they be handled
in the same way as internally defined "external" declarations? I
guess so, even if they may be shared between modules.
There's 2 possibilities I think :
- For each file we generate the wrapping functions
- For each pxd file, generate a file containing the wrapping functions
Right. I don't see a problem with any of the two, nor a major advantage on
either side. The first sounds a bit simpler.
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
