On 05/30/2015 12:13 PM, Serhiy Storchaka wrote:
On 30.05.15 18:45, Ron Adam wrote:
While trying to debug a problem and thinking that it may be an issue with circular imports, I come up with an interesting idea that might be of value. It wasn't a circular import problem in this case, but I may have found the actual bug sooner if I didn't need to be concerned about that possibility.
I have had some difficulty splitting larger modules into smaller modules in the past where if I split the code by functionality, it doesn't correspond with how the code is organized by dependency. The result is an imported module needs to import the module it's imported into. Which just doesn't feel right to me.
The solution I found was to call a function to explicitly set the shared items in the imported module.
Why not move all shared objects in common module? Then in both main and parse module you can write
from common import *
As I said, sometimes I prefer to organise things by function rather than dependency. The point is this fits a somewhat different pattern than when you have independent common objects. These can be inter-dependent shared objects that would require a circular imports. So common may need an "import __main__ as main" in order for the items that are imported with "import *" to work. One argument might be the organisation of the code is wrong if that is needed, or the may be a better way to organise it. While that is a valid point, it may not be the only factor involved in deciding how to organise the code. I also like to avoid "import *" except when importing very general and common utility functions. ie.. "from math import *". Cheers, Ron