Namespaces: memory vs 'pollution'

[Thomas Jollans]

On 22/07/2019 07.06, DL Neil wrote:
>
> 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


Just FYI, in the scientific Python community certain short abbreviations
are the norm. Many modules have a ‘standard’ abbreviation that most
people use, minimizing confusion.

import numpy as np
import matplotlib as mpl
from matplotlib import pyplot as plt
import pandas as pd
import xarray as xr

and so on.

As long as you're consistent and use the same abbreviation across your
entire codebase, and you put the imports at the top where people can
find them, I think using 2–4 letter abbreviations, even without any
decoration, is a fine approach.

-- Thomas


> - 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!