[Tutor] Module Architecture

[dn]

On 16/08/2022 04.07, Gordon Stewart wrote:
> I'd like some recommendations on how to design and layout a module.
> There are any number of sources to help with discrete coding problems (on
> this site for instance), but I'm interested in a higher level view on how
> to assemble these discrete components into something easily maintained and
> understood.  I'm a solo hobby developer with no external collaboration.

IMHO @Alan's answer is excellent advice.


Looking at things another way: whilst separating units into modules is
very good practice for namespace-separation, 'cleanliness',
sanitisation, etc; and encouraging the ideas of cohesion etc - doing one
thing and doing it well, self-contained, ... there also is the
Object-Oriented philosophy (?'dream') of "reusability".

If a routine will only be used in the single use-case/activity, store it
with that activity. NB "with" could be taken to mean same "module" ie
.py file; or "directory".

If the routine will be used in other use-cases, for example, the class
which defines a 'member', then store that as part of 'the application'
or "package".

Wider still: if the routine might be used by other applications (nothing
to do with 'membership'), eg database management, then create a
'library' which will be accessible to 'membership' and any other
DB-using application.

Do you see how the different 'widths' of usage lead to an organisation?


You will find similar structure/advice discussed in PEP-008 the "Style
Guide for Python Code" [in the Python Standard Library]
https://peps.python.org/pep-0008/#imports

(although in my advanced state of decrepitude, if there is something of
a list of import-s, I do separate the categories and may even label them
with a comment-separator (ooh, ahh - suck in your breath in case the
Python-gods strike me down!) - but then your mind is probably less
cluttered than mine, so YMMV applies!)
-- 
Regards,
=dn