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