Imports visibility in imported modules problem

[Maric Michaud]

Le Sunday 24 August 2008 12:11:03 Mohamed Yousef, vous avez écrit :
> On Sun, Aug 24, 2008 at 5:54 AM, Patrick Maupin <pmaupin at gmail.com> wrote:
> > On Aug 23, 7:27 pm, "Mohamed Yousef" <harrr... at gmail.com> wrote:
> >> 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
>
> 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 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.
>
> 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.

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

> >> 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.
>
> 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).

-- 
_____________

Maric Michaud