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
--
https://mail.python.org/mailman/listinfo/python-list
