I was incorrect. The runtime issue is caused by imported by out of order module_init code. Namely, before all python (but not cython) modules in a circular import are done importing, it is possible for code to be executed that creates a instance of a class from one of the other modules whose module_init function has not been finished. The solution might seems to be to move the non-import nodes from module_init to another module_init2, and call module_init2 on each imported (but not cimported) module only after the current module has finished executing module_init. This should guarantee that any code that creates new instances of classes at the global module level only executes after all recursive imports have finished executing. Thus it should be possible to solve the cimport issue without any major compiler changes.
-- Gary Furnish On 2/24/08, Bill Furnish <[EMAIL PROTECTED]> wrote: > > There are actually two issues here which I am currently working on a patch > for. One, code generation for classes is based on order of imported > modules, not on the base class dependencies between the classes. I ended up > sorting them by dependencies and this fixed that issue. There is a second > issue I am still working on which is that cython does not always generate > correct module initialization code in the circular dependence case. This > results in the attribute error that is sometimes observed. It seems like > this arises from circular imports in the python code and not in the symbolic > code. I think that it arises because creating classes involves __init__ and > thus we end up with circular imports in python. I feel liike we ought to be > able to detect this somehow though and prevent it. However, the problem > seems to me to be that currently cython source files are compiled and > linked into separate objects. It may be necessary to implement a link time > solution to the issue by linking multiple cython files together and then > not load the modules that are linked together, but instead leave the > pointers to be relocated by the linker. > > On 2/24/08, David Harvey <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > In Sage, if I try to add > > > > from sage.rings.integer cimport Integer > > > > at the top of sage/misc/misc_c.pyx, everything compiles fine, but > > then I get some weird import error when I start up sage. > > > > (I'm sorry, I don't know enough about cython to reproduce this in a > > standalone cython program, I only know how to make it happen in sage.) > > > > It looks like a "circular cimport problem". I found this post by Greg > > Ewing which seems relevant, but it's a bit old now, and I don't quite > > understand what he's saying: > > > > http://osdir.com/ml/python.pyrex/2006-06/msg00020.html > > > > Is there any way to successfully cimport Integer into that module? Or > > do I need to just put the code that references Integer in some other > > random place which is guaranteed to get loaded after > > sage.rings.integer? (This would be a bit annoying....) > > > > I don't quite understand why circular cimports should exist, since I > > thought these kinds of things got resolved at compile time. > > > > david > > > > _______________________________________________ > > Cython-dev mailing list > > Cython-dev@codespeak.net > > http://codespeak.net/mailman/listinfo/cython-dev > > > >
_______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
