Improvement to imports, what is a better way ?

[Weatherby,Gerard]

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.

As the fictional Jack McCoy ( https://en.wikipedia.org/wiki/Jack_McCoy) would say --

Objection: Assumes facts not in evidence!

If I read A.py:

import …
# many lines of code
x = obscure_module.widget(4)

I know immediately where the function widget is.

If I read B.py
from obscure_module import widget
# many lines of code
x = widget(4)

Now I have to find out where the heck “widget” came from

And C.py

from obscure_module import widget as gadget
# many lines of code
x = gadget(4)

which is actually easier and harder to read.  Personally, I’m much happier with A.py than B.py or C.py.







From: Python-list <python-list-bounces+gweatherby=uchc.edu at python.org> on behalf of dn via Python-list <python-list at python.org>
Date: Wednesday, January 18, 2023 at 3:49 PM
To: python-list at python.org <python-list at python.org>
Subject: Re: Improvement to imports, what is a better way ?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

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
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!nUeLMY3g5EV0oaXoGfknoeDOLU9qMoIxHOe7jhHbHfN1v7-wj17OJCgqL_IyHpAr0EN8gyzj5ZEQZB9_A-rB3A_Q5g$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!nUeLMY3g5EV0oaXoGfknoeDOLU9qMoIxHOe7jhHbHfN1v7-wj17OJCgqL_IyHpAr0EN8gyzj5ZEQZB9_A-rB3A_Q5g$>