Module import best practice

[DL Neil]

Rich,


On 26/03/20 9:09 AM, Rich Shepard wrote:
> I'm writing an application using Python3 and Tkinter. The views/ directory
> contain multiple modules, including one called commonDlgs.py. This contains
> classes (such as those for validating data entry) used by all the data 
> entry
> views. Some classes in commonDlgs imports other modules.
> 
> My question is whether to import into each view class those modules needed
> by it or import all supporting modules at the top of commonDlgs.py, then
> import that module in each view with:
> 
> from . import commonDlgs as cd
> 
> rather than importing specific classes in each view module?


My personal approach is to follow 'the Zen of Python' and prefer 
"explicit" over "implicit".
(it helps beginners, as well as us old-fogies whose minds cannot retain 
things for very long)

I see little point in importing 'stuff' that's not used. On the other 
hand, if that becomes the criteria for splitting one's code-base into 
ever more modules, likely it will cause more trouble than good. Plus if 
a module contains two classes but you only import one, the entire class 
is imported anyway - so, it's not like you're saving CPU-time or 
storage-space!

As you've probably realised by now, there is a 'happy medium', but it's 
impossible to lay down a 'law'. It's probably one of those 'feelings' 
that comes with experience - and the only way you can gain experience is...

Another problem with trying to gain such experience, is that Python has 
changed. You have demonstrated a "relative import". Its introduction 
(and the importlib, and "packages") opened-up a whole new vista* of 
opportunities), but much of the material available on-the-web pre-dates 
this.
* Microsoft-ies may be confused by the real meaning of this word.


Aside from the drudge of typing, there are two (main) potential issues 
to be considered - and hopefully avoided: proliferation and circular 
references.


Proliferation:

My mother-in-law had five kids. At first, it worried me that in trying 
to attract my attention, she would 'pop the list' - in her confusion, 
calling out each of her kids' names in-turn, before she happened upon mine.
(especially given that most of them were/are girls!)

There seem to be a large-ish number of classes and modules to manage. 
The more of these you have, the harder it is to keep track of 
which-is-where. That said, if you have a multiplicity of classes and try 
to group them into fewer modules, the problem may not go away; unless 
you are able to group them by function, theme, or stage/part of the 
system in which they are used.

When faced with my mother-in-law's problem, many people resort to a 
tactic such as calling-out "hey you" [varies by culture and language]. 
Python has a similar facility! You can turn your "views/ directory" 
(which presumably contains a number of modules) into a "package".

Remember the __init__.py file (the "file" not the similarly-named object 
instantiation method!) which is normally an empty, useless-looking 
appendage? [no comments about my head, please!] This can be populated 
with a list of moduleNMs (etc), thus creating a grouping-effect, 
shortening the import process, and lightening your cognitive- and 
management-loads.


Circular references:

If you have a bunch of import-able modules which in-turn import other 
modules, it is possible to become a dog chasing its own tail. [this is 
loads of fun, until your teeth sink firmly into said tail. Yow, ouch! 
(I'm told, er, by a friend - you must understand?) ]

If there is module "fred.py" and it calls a class in "barney.py" but 
barney can't do anything without advice from "wilma.py", then that is 
all fine and can become the bed-rock of your program [sorry!].

However, if wilma needs to first confirm with "betty.py", who like any 
responsible wife goes to fred and asks "What are you up-to now, Fred?", 
fred will make excuses and blame barney, who in-turn will call for help 
and understanding from betty, who will want to put her head together 
with wilma's to decide how best to sort-out their men-folk, and...

Are you confused yet? So would the Python interpreter be, giving-up and 
throwing such code all over the floor!

Accordingly, you must design and manage the structure of your 
application - classes and modules should be encouraged not to gossip 
amongst themselves. The ComSc terms here include: "encapsulation", 
"coupling" and "cohesion", and because this is another area where ONE 
precise answer for the general case does not exist, the 
counter-considerations of such are "decoupling" and "the Law of Demeter"...

Once again, read carefully because many ComSc-level web.refs will 
concern themselves with language-related matters, which may not apply in 
Python!


Hoping this non-answer helps, by leaving you with reading topics which 
will realise advice for the concerns you had/hadn't noted to-date.


Now, it's time to get back to the (salt-)mines, if we expect to put 
(dino-)steaks on the table tonight...
[https://www.youtube.com/watch?v=2s13X66BFd8]
-- 
Regards =dn