[Python-ideas] Explicitly shared objects with sub modules vs import

[Ron Adam]

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