Imports and dot-notation

[dn]

On 09/08/2023 22.30, Oliver Schinagl via Python-list wrote:
...> Looking at a python projects code and repository layout, we see the
> following directory structure.
> 
> /project/core
> /project/components/module1
> ...
> /project/components/moduleN
> /projects/util
...> Some modules import other modules, and I see (at the very least) two
> (kind of three?) different ways of doing so.
> 
> `from project.components.module1 import function1, function2 as func, 
> CONST1, CONST2 as CONST`
> 
> or maybe even (which has as an advantage that it becomes clear which 
> namespace something belongs to
> 
> `from project.components.module1 import function1, function2 as 
> module1_function2, CONST1, CONST2 as MODULE1_CONST2`
> 
> but then it really just becomes personal preference, as the number of 
> characters saved on typing is almost negative (due to having a more 
> complex import).
> 
> but also the dot notation being used
> 
> `from project.components import module1`
> 
> where obviously the functions are invoked as `module1.function1` etc

Firstly, the path followed will depend upon the starting position!

Keep reading and you should come across a reference to 'hobgoblin of 
little minds'.

What should we be concentrating on/about? If 'naming' is a great (?the 
greatest) challenge of programming, surely remembering the names of 
classes, methods, functions, modules, etc; follows...
(and by implication, as you've illustrated, perhaps where they 
come-from), ie code is read more often than it is written, so think 
about comprehension rather than typing!


If one (one's team!) frequently uses a module, then a jargon may 
develop. For example:

import numpy as np
...
a = np.arange(6)

In which case, those au-fait with the jargon know that the "np." prefix 
tells them where "arange()" can be found - conversely, that if the IDE 
doesn't alert, that np/numpy must be (first) import-ed.

However, there is a cognitive-load to 'translate' "np" into "numpy". Not 
much, but then over-load is not a single thought but the combination of 
'everything'.

The second option (OP) is very (laboriously) clear in mapping the source 
of each function or constant. By way of comparison then, the code may 
now appear cluttered, because there's so much text to read. There would 
be less if an abbreviation were used.

The dev.tool in-use may also influence this decision. If hovering-over 
an identifier reveals source-information, what value the extra code? 
Intelligent completion also reduces relevance of 'number of characters 
saved on typing'.

Accordingly, give frequently-used functions/modules the abbreviation 
treatment -but only if YOU feel it right. Otherwise, use a longer-form 
to improve readability/comprehension.

THE answer will thus vary by library/package/module, by application, and 
by coder (jargon works best if 'all' use it/understand same).

Side note: Using "...import identifier, ..." does not save storage-space 
over "import module" (the whole module is imported regardless, IIRC), 
however it does form an "interface" and thus recommend leaning into the 
"Interface Segregation Principle", or as our InfoSec brethren would say 
'the principle of least privilege'. Accordingly, prefer "from ... import 
... as ...".

-- 
Regards,
=dn