On 22/07/19 5:30 AM, Roel Schroeven wrote:
DL Neil schreef op 21/07/2019 om 2:02:
How do you remember to from-import- 'everything' that is needed?
... > Upon closer inspection, I realised it didn't just fail; it
failed badly!
Some silly, little, boy had imported the PythonEnvironment class but
failed to ALSO import PythonVersionError. So, the reported error was not
the expected exception!
...
Is there some 'easy way' to make sure that one doesn't just import the
desired class, but also remembers to import 'everything else' that might
be necessary. In this case, it'd be rather nice to:
from environment_module import Python*
NB this is a syntax error, and won't import both the PythonEnvironment
and PythonVersionError classes.
> ...
What do you do to (respecting purism) ensure 'everything' (necessary) is
imported (and nothing more), preferably without relying upon (faulty, in
my case) human-memory or reading through volumes of code/documentation?
This is one of the advantages of using import instead of from-import.
import environment_module
...
try:
....
# Just an example, since I don't know PythonEnvironment
env = environment_module.PythonEnvironment()
...
except environment_module.PythonVersionError:
# Handle the exception
In this case you have a pretty long module name (by the way, you could
probably shorten it by removing _module; there's normally no need to
repeat it in the name of a module that it's a module), making repeating
it everywhere somewhat awkward. You can import the module using another
name to work around that:
import environment_module as envmod
...
try:
....
# Just an example, since I don't know PythonEnvironment
env = envmod.PythonEnvironment()
...
except envmod.PythonVersionError:
# Handle the exception
Greetings to Belgians, and thanks!
Yes, I like this (interestingly, I recall posing a question some months
back, asking how many of us bother to check for import exceptions).
Long names: agreed, although I don't worry about it too much because
competent editors 'pop-up' suggestions as one types. (incidentally, you
are correct - I wouldn't really use that naming system, but inserted the
word "module" in a bid to make the example illustrative)
The opposite is even worse (and sometimes working with statisticians I'm
often given 'algebra' with one-letter 'variable names') - in the general
case, I criticise non-obvious abbreviations in code-review. Yet...
Yesterday, I went 'full-circle' around the options for import statements
(and some importlib facilities), looking at the effects on 'namespace
pollution' and trying to find some sort of "wild-card" method. In the
end, my conclusions were close-to, but not as well-developed as the above.
Current thoughts:
import environment_module as em
- so, even more of an abbreviation than suggested!?
- I rarely need to write a long list of import statements, so there
won't be many.
- not normally using such abbreviations in my code, they will stand-out.
- considered using upper-case, eg "EM" - it is a form of constant after-all
- considered adding a single under(-line) suffix, eg "em_" (on the basis
of "made you think"). No, don't make me think (too much)!
- so, perhaps a two-letter abbreviation with a single under(-line), eg
"e_m", won't be confused with other naming conventions and yet
stands-out. (sadly, that is "stands-out" to me, but 'everyone else'
won't know its significance...)
The try...except construct is a brilliant idea because it does exactly
what I asked - requires both the class (what I wanted to include) AND
the custom-exception class (what it needs included).
If the class does not have any related error classes, then the
try...except can simply check for 'exists?'...
It's a habit I'm about to adopt. Many thanks!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
