Improvement to imports, what is a better way ?

[Paul Bryan]

On Thu, 2023-01-19 at 09:47 +1300, dn via Python-list wrote:

> 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.

I sympathize with this issue. I've pushed the line limit to 96, which
in my case removed this pain point. My argument—though subjective—is
that we have wide screens now, and it's quite unlikely production code
will be accessed through a vintage VT-100 terminal or printed on a 80-
column dot-matrix printer. That said, even if you stick to PEP-8
proper, `black` does most of the formatting work, and it seems to do a
reasonable job despite longer module identifiers.

> 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.

I tend to agree this can be a problem in some cases, but I think those
can be made manageable. For brevity's sake, I import often-used data
types directly into the module's name space. It's far more rare that I
try to abbreviate a module name; common ones like importing pandas as
pd is a good counterexample.

> 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 ...'.

I'm not entirely sure what you mean by not a Python module. Even in
test modules, I would only import what's required. If it turns out
`fetch_the_file` is called dozens of times or more, I would have no
qualm about importing it directly into the test module's namespace so
that it doesn't need to be prefixed at all.