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