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