I was incorrect.&nbsp; The runtime issue is caused by imported by out of order module_init code.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; Thus it should be possible to solve the cimport issue without any major compiler changes.&nbsp; <br>
<br>-- Gary Furnish<br><br><div><span class="gmail_quote">On 2/24/08, <b class="gmail_sendername">Bill Furnish</b> &lt;<a href="mailto:bill@indirectproof.net">bill@indirectproof.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are actually two issues here which I am currently working on a patch for.&nbsp; One, code generation for classes is based on order of imported modules, not on the base class dependencies between the classes.&nbsp; I ended up sorting them by dependencies and this fixed that issue.&nbsp; There is a second issue I am still working on which is that <span id="st" name="st" class="st">cython</span> does not always generate correct module initialization code in the circular dependence case.&nbsp; This results in the attribute error that is sometimes observed.&nbsp; It seems like this arises from circular imports in the python code and not in the symbolic code.&nbsp; I think that it arises because creating classes involves __init__ and thus we end up with circular imports in python.&nbsp; I feel liike we ought to be able to detect this somehow though and prevent it.&nbsp; However, the problem seems to me to be that currently <span id="st" name="st" class="st">cython</span> source files are compiled and linked into separate objects.&nbsp; It may be necessary to implement a link time solution to the issue by linking multiple <span id="st" name="st" class="st">cython</span> files together and then not load the modules that are linked together, but instead leave the pointers to be relocated by the linker. &nbsp; <br>
<div><span class="e" id="q_1184ee7a502954f2_1">
<br><div><span class="gmail_quote">On 2/24/08, <b class="gmail_sendername">David Harvey</b> &lt;<a href="mailto:dmharvey@math.harvard.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dmharvey@math.harvard.edu</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi,<br> <br> In Sage, if I try to add<br> <br> from sage.rings.integer cimport Integer<br> <br> at the top of sage/misc/misc_c.pyx, everything compiles fine, but<br> then I get some weird import error when I start up sage.<br>

 <br> (I&#39;m sorry, I don&#39;t know enough about cython to reproduce this in a<br> standalone cython program, I only know how to make it happen in sage.)<br> <br> It looks like a &quot;circular cimport problem&quot;. I found this post by Greg<br>

 Ewing which seems relevant, but it&#39;s a bit old now, and I don&#39;t quite<br> understand what he&#39;s saying:<br> <br> <a href="http://osdir.com/ml/python.pyrex/2006-06/msg00020.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://osdir.com/ml/python.pyrex/2006-06/msg00020.html</a><br>

 <br> Is there any way to successfully cimport Integer into that module? Or<br> do I need to just put the code that references Integer in some other<br> random place which is guaranteed to get loaded after<br> sage.rings.integer? (This would be a bit annoying....)<br>

 <br> I don&#39;t quite understand why circular cimports should exist, since I<br> thought these kinds of things got resolved at compile time.<br> <br> david<br> <br> _______________________________________________<br> Cython-dev mailing list<br>

 <a href="mailto:Cython-dev@codespeak.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Cython-dev@codespeak.net</a><br> <a href="http://codespeak.net/mailman/listinfo/cython-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://codespeak.net/mailman/listinfo/cython-dev</a><br>
 </blockquote></div><br>
</span></div></blockquote></div><br>