<p dir="ltr"><br>
On 4 Apr 2013 19:37, "Kristján Valur Jónsson" <<a href="mailto:kristjan@ccpgames.com">kristjan@ccpgames.com</a>> wrote:<br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: Eric Snow [mailto:<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>]<br>
> > Sent: 4. apríl 2013 04:57<br>
> > > imported by both of the original modules. At that point, the code is<br>
> > > cleaner and more decoupled, and the uneven circular import support<br>
> > ceases to be a problem for that application.<br>
> ><br>
> > +1<br>
><br>
> I tried to make the point in an earlier mail that I don't think that we ought to let our personal opinions de-jour on software architecture put a constraint on our language features.<br>
> There can be good and valid reasons to put things that depend on each other in separate modules, for example when trying to separate modules by functionality or simply when splitting a long file into two.<br>
> Notice that cyclic dependencies are allowed _within_ a module file.  Imagine if we decided that we could only refer to objects _previously_  declared within a .py file, because it encouraged the good design practice of factoring out common dependencies.<br>

> Dependency graphs of software entities can sadly not always be reduced into a DAG, and we should, IMHO, by no means force people to keep each cygle in the dependency graph within a single .py module.</p>
<p dir="ltr">That's why it's just a reason none of the current import system devs are inclined to work on it, rather than a reason for rejecting proposals and tested patches that give improved behaviour.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> K<br>
><br>
><br>
</p>