Namespaces: memory vs 'pollution'
DL Neil
PythonList at DancesWithMice.info
Mon Jul 22 01:06:30 EDT 2019
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
More information about the Python-list
mailing list