Imports visibility in imported modules problem

[Mohamed Yousef]

Hello ,

The problem I'm asking about is how can imported modules be aware of
other imported modules so they don't have to re-import them (avoiding
importing problems and Consicing code and imports )
Take Example :-
in A.py :-

import B
print dir() # no problems we can see B which contain re module and C module
B.C.W() # our problem here we get an empty list

in B.py :-

import re
import C

in C.py :-

def W():
print dir() # when called from A we get [] though other imports
has been made to re and others

my goal is basically making W() aware of the re module when called from A
----
why am i doing this in the first place I'm in the process of a medium
project where imports of modules start to make a jungle and i wanted
all needed imports to be in a single file (namely __init__.py) and
then all imports are made once and other modules feel it

another reason to do this that my project is offering 2 interfaces
(Console and GUI through Qt) and i needed a general state class (
whether i'm in Console or GUI mode) to be available for all , for
determining state and some public functions ,and just injecting
Imports everywhere seems a bad technique in many ways (debugging ,
modifying ...etc )

in PHP "Require" would do the trick neatly ... so is there is
something I'm missing here or the whole technique is bad in which case
what do you suggest ?

Thanks,

Regards,
Mohamed Yousef

 

[Patrick Maupin]

The problem I'm asking about is how can imported modules be aware of
other imported modules so they don't have to re-import them (avoiding
importing problems and Consicing code and imports )

You could import sys and look at sys.modules

why am i doing this in the first place I'm in the process of a medium
project where imports of modules start to make a jungle and i wanted
all needed imports to be in a single file (namely __init__.py) and
then all imports are made once and other modules feel it

This doesn't sound like a good idea. If A imports a module which is
automatically imported into B's namespace, that sounds like a
maintenance nightmare.

another reason to do this that my project is offering 2 interfaces
(Console and GUI through Qt) and i needed a general state class (
whether i'm in Console or GUI mode) to be available for all , for
determining state and some public functions ,and just injecting
Imports everywhere seems a bad technique in many ways (debugging ,
modifying ...etc )

I still don't understand.

in PHP "Require" would do the trick neatly ... so is there is
something I'm missing here or the whole technique is bad in which case
what do you suggest ?

I don't know what to suggest, in that you haven't yet stated anything
that appears to be a problem with how Python works. If two different
modules import the same third module, there is no big performance
penalty. The initialization code for the third module is only
executed on the first import, and the cost of having the import
statement find the already imported module is trivial.

 

[Mohamed Yousef]

You could import sys and look at sys.modules

no even if you imported sys or used dir you will see no re in W() from
A . and you can even try to use re and will see

This doesn't sound like a good idea. If A imports a module which is
automatically imported into B's namespace, that sounds like a
maintenance nightmare.

why ?
this saves time and consices whole package imports in one file
and maintaining it is easier (eg. you will never have circuular imports)

I still don't understand.

put it another way a general variable in all modules
and some functions visible in all modules

I don't know what to suggest, in that you haven't yet stated anything
that appears to be a problem with how Python works. If two different
modules import the same third module, there is no big performance
penalty. The initialization code for the third module is only
executed on the first import, and the cost of having the import
statement find the already imported module is trivial.

it's not performance it's the jungle resulting
many imports in every file and suppose i changed the module used in
all modules name
guess what , it will have to be renamed in every import to it in all modules

 

[Maric Michaud]

Le Sunday 24 August 2008 12:11:03 Mohamed Yousef, vous avez écrit :

no even if you imported sys or used dir you will see no re in W() from
A . and you can even try to use re and will see


why ?
this saves time and consices whole package imports in one file
and maintaining it is easier

Maintaining is easier ? Not at all, refactoring maybe but it's not a big deal,
you must be convinced that module names are exactly as APIs, they are not
intended to change between versions.

BTW you could do that by importing all you need in one module, say libs.py,
and from libs import * in all you r package modules.
But htis considered a very bad practice by python developpers as PEP 8 states,
it break on of the zen's rule : "explicit is better than implicit".

Really, it is very good for reading and *maintaining* purpose to have all the
names used in one's module be easily found in the few import statments at the
top of the file.

In case you really need to make available a name to an arbitrary piece of code
(not a common scheme though), you could easily add it to the __builtin__
module, but if you know exactly what you do.

(eg. you will never have circuular imports)

No, circular imports are another problem that wouldn't be resolved by your
suggestion.

put it another way a general variable in all modules
and some functions visible in all modules

This has no use case in python, even builtin names are overriden by the simple
affectation stamtent, if you want to modify a global name, you need access it
as an attribute of a specific namespace.

glob.py:

A=0
B=0

script.py:

import glob
from glob import A

A=1
glob.B =1
print A, B, glob.A, glob.B

will print 1, 1, 0, 1.

it's not performance it's the jungle resulting
many imports in every file and suppose i changed the module used in
all modules name
guess what , it will have to be renamed in every import to it in all
modules --

(cf my previous comment).