Improvement to imports, what is a better way ?

[dn]

On 19/01/2023 08.56, Mats Wichmann wrote:
> On 1/18/23 12:29, Paul Bryan wrote:
...

>>> import os as                        os
>>> import sys as                       sys
>>> import importlib as                 importlib
> 
> A general comment: there are some very common "import ... as" idioms 
> (for example, it seems like *everyone* does "import pandas as pd") and 
> those are okay to follow, but in general I would stay away from trying 
> to give everything short-names.  Each module imported with a name other 
> than their own is a memory burden for the reader (maybe even for you!).
> 
>>> import aboutTime as         tt      # Time dates timestamps and the
>>> like
>>> import avMedia as           av      # Audio and maybe video 'someday'
>>> well definitely lots of TTS text to speech
>>> import basicSwitchboard as  sc      # First switchboard lurking.
>>> Kickoff to sequence viewers
> 
> Any decent editor these days will autocomplete for you, so there's 
> really not much if any typing burden in using the full names.

Have vacillated on aspects of this topic, over the years. Currently I'm 
in favor of abbreviations and not only the commonly-accepted/-used ones, 
eg np for numpy.
(but am keen to learn from your wisdom)

I've argued the auto-complete cf typing point. So, that not at-issue.

The longer an identifier, the more it 'pushes' code over to the right or 
to expand over multiple screen-lines. Some thoughts on this are behind 
PEP-008 philosophies, eg line-limit.

In the body of the code, if every time an external identifier is used it 
must be prefixed by a full 'path', the cognitive "burden" shifts from 
the aspect highlighted (above), to a reading-burden. Thus, (in extreme 
cases) moving towards a 'wall of text' problem.

The primary interest is to remove "burden" aka complexity.

In using TDD, code is constructed module-by-module (not necessarily a 
Python Module). So, when it comes time to call avMedia.fetch_the_file() 
[sic] there is little thinking about the "avMedia" bit. The emphasis is 
on the function-name, and it's parameters. 'I need that file so that I 
can ...'.

Using the IDE-as-a-tool argument (similar to above): if I miss-out, 
mistype, use the wrong abbreviation, or otherwise fail to identify where 
fetch_the_file() is located, the IDE will immediately tell me.
(dn you're wrong - again!)

Accordingly, the abbreviation/full-module-name is almost taken-on-trust. 
(you're going to prove/test the linkage, either way, right?)


Personal Biases:
- TDD
- when starting to write the program[me]-code one of the first steps is 
to marshal resources, which includes the question: which functions will 
be called and thus which Python-modules should be imported? Thus, 
listing all imports 'at the top' is a separable task.
- an early language learned (back-when) was COBOL, which has a formal 
structure and separation between elements/phases of a program[me]'s 
construction and execution. Some such thinking no doubt lingers...

-- 
Regards,
=dn