multiple import of a load of variables

[Torsten Bronger]

Hallöchen!

I have a file that looks a little bit like a C header file with a
long list of variables (actually constants) definitions, e.g.

VI_ATTR_TIMO = 0x54378
....

Actually I need this in a couple of low-level modules that are
imported into the main module, and in the main module itself. They
may be also used in the programs that import the main module.

Probably it doesn't mean a significant loss of performance anyway
since all of it is done only at startup, but I wonder whether it's
better to keep everything that depends on this "header" file
together so that it must be looked over by Python only once. Is
this correct, or is there some sort of implicit optimisation that
makes both variants almost equivalent?

Tschö,
Torsten.

 

[Fuzzyman]

Hallöchen!

I have a file that looks a little bit like a C header file with a
long list of variables (actually constants) definitions, e.g.

VI_ATTR_TIMO = 0x54378
...

Actually I need this in a couple of low-level modules that are
imported into the main module, and in the main module itself. They
may be also used in the programs that import the main module.

Probably it doesn't mean a significant loss of performance anyway
since all of it is done only at startup, but I wonder whether it's
better to keep everything that depends on this "header" file
together so that it must be looked over by Python only once. Is
this correct, or is there some sort of implicit optimisation that
makes both variants almost equivalent?

I'm not entirely clear what you are trying to do *but* - if you import
the same module in several places (per interpreter instance of course)
the import will only be done *once*. The other import statments just
make that namespace available from the namespace that does the import.

This means there is little extra overhead for importing a module that
has already been imported elsewhere.

HTH ?

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

 

[Torsten Bronger]

Hallöchen!

[...]

I'm not entirely clear what you are trying to do

The following: "variables.py" looks like this

a = 1
b = 2

Then I have helper_a.py, helper_b.py, and helper_c.py which begin
with

from variables import *

And finally, my_module.py starts with

from variables import *
from helper_a.py import *
from helper_c.py import *
from helper_c.py import *

Now imagine that variables.py contained not only two but hundreds of
variables. Is this then still the most effective approach?

*but* - if you import the same module in several places (per
interpreter instance of course) the import will only be done
*once*. The other import statments just make that namespace
available from the namespace that does the import.

Even if I use "from"?

Tschö,
Torsten.

 

[Fuzzyman]

Hallöchen!

[...]

I'm not entirely clear what you are trying to do

The following: "variables.py" looks like this

a = 1
b = 2

Then I have helper_a.py, helper_b.py, and helper_c.py which begin
with

from variables import *

And finally, my_module.py starts with

from variables import *
from helper_a.py import *
from helper_c.py import *
from helper_c.py import *

Now imagine that variables.py contained not only two but hundreds of
variables. Is this then still the most effective approach?

Hello Torsten,

This looks like the most effective approach to me. The additional cost
of the extra import statements would be very low. The alternative would
be to parse a config file and pass a data structure (containing all the
variables) between your modules. I can't imagine there is less overhead
in this. Either that or refactor so you only use the variables in one
place.

Even if I use "from"?

Yes - all you do with the 'from' approach is get a direct reference to
that value, it still exists in it's original namespace.

import module
value = module.value
and :
from module import value

are exactly equivalent. The only difference is that the first construct
makes the whole of the 'module' namespace available as well - it no
less exists with the second construct though... you're just not keeping
a reference to it directly.

Not using the 'from' construct requires a bit of extra typing - but is
more explicit as to where the variables are coming from. This might
make your code a bit more readable.

Regards,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Jeff Shannon]

Hallöchen!

[...]

I'm not entirely clear what you are trying to do

The following: "variables.py" looks like this

a = 1
b = 2

Then I have helper_a.py, helper_b.py, and helper_c.py which begin
with

from variables import *

And finally, my_module.py starts with

from variables import *
from helper_a.py import *
from helper_c.py import *
from helper_c.py import *

Now imagine that variables.py contained not only two but hundreds of
variables. Is this then still the most effective approach?

Ugh. I really don't like the 'from module import *' approach in any
case, but here, you're binding each name from variables.py at least
seven times. Now, it's not like binding names is all *that*
expensive, but still... I'd call this a code smell.

You say that users of my_module.py may need direct access to these
variables; to do that well, it does make some sense that my_module
should import * from variables. However, I doubt there's any good
justification for importing the helper modules that way, nor for
importing * from variables in each of the helper modules.

If you use normal imports in those cases, then once variables.py has
been loaded into sys.modules (i.e. imported for the first time), you
create n+3 name bindings as opposed to the 7*n bindings your method is
creating, where n is the number of names in variables.py. (The '+6'
is the 'variables' name in each of the helper modules.)

More importantly, you get clearer code that's easier to maintain and
troubleshoot. This fact is far more important than the cost of
creating name bindings, or any other form of 'efficiency' that is
likely to apply. As far as I'm concerned, if you're just going to
'import *' your helper modules, you might as well leave the whole mess
as one big file, because you're throwing away almost all of the
benefits of dividing it into modules.

Jeff Shannon