Namespaces: memory vs 'pollution'

[DL Neil]

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