By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,222 Members | 2,354 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,222 IT Pros & Developers. It's quick & easy.

merging the global namespaces of two modules

P: n/a
Hi,

just an import problem:
a program imports two modules, modA and modB, each module do not known anything
about the other module (i.e. no cross imports in them), both modules needs to
refer to some functions that are defined in the global namespace of the other
module. There is a possible solution? In other words, can the importing program
cover in some way the lack of cross imports between the modules?
Thank in advance for any help.

F. Pollastri
Jun 27 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Can you be more specific? modA and modB don't import from each other
but both need to access objects in the global namespace of what
module? The controlling application? Or do you mean that, for
example, modA needs to access some functions in modB, but does not
have import statements to do so, and you want the controlling program
to do the imports for it? If that is the case, that is bad
programming practice in Python. Python is not C and you can't just
share header files :)

If you need to avoid recursive import conflicts, you can perform your
imports at the top of functions that use objects from another module.

Jeff
http://www.artfulcode.net
Jun 27 '08 #2

P: n/a
Fabrizio Pollastri a écrit :
Hi,

just an import problem:
a program imports two modules, modA and modB, each module do not known
anything about the other module (i.e. no cross imports in them), both
modules needs to refer to some functions that are defined in the global
namespace of the other module.
IOW, you have a circular dependency between modA and modB.
There is a possible solution?
The obvious one : extract the relevant functions from modA and modB into
modC and import modC in both modA and modB.

If not applyable in your case, please provide more informations.

Jun 27 '08 #3

P: n/a
Jeff wrote:
Can you be more specific? modA and modB don't import from each other
but both need to access objects in the global namespace of what
module? The controlling application?
Or do you mean that, for
example, modA needs to access some functions in modB, but does not
have import statements to do so, and you want the controlling program
to do the imports for it?
Exactly this.
If that is the case, that is bad
programming practice in Python. Python is not C and you can't just
share header files :)
Ok. I know that I want a python import to behave like a C include, it is so bad?

The motivation arise from a family of applications that import, among others,
two modules: a basic one and a specific one. The specific one is chosen from a
set of modules at import time depending on other imported modules, so the basic
module can known its external references against the specific module only at run
time.

One solution can be:
-the application imports the basic module,
-the basic module selects the proper specific module among the allowable
specific modules,
-the basic module imports the selected module with an __import__ call equivalent
to "import selected_module_X as select_module",
-Any reference to the specific module in the basic module is written in the form
"selected_module.object_name".

Any better solution?
Fabrizio.
Jun 27 '08 #4

P: n/a
Fabrizio Pollastri wrote:
Jeff wrote:
>Can you be more specific? modA and modB don't import from each other
but both need to access objects in the global namespace of what
module? The controlling application?
>Or do you mean that, for
example, modA needs to access some functions in modB, but does not
have import statements to do so, and you want the controlling program
to do the imports for it?

Exactly this.
>If that is the case, that is bad
programming practice in Python. Python is not C and you can't just
share header files :)

Ok. I know that I want a python import to behave like a C include, it is
so bad?

The motivation arise from a family of applications that import, among
others, two modules: a basic one and a specific one. The specific one is
chosen from a set of modules at import time depending on other imported
modules, so the basic module can known its external references against the
specific module only at run time.

One solution can be:
-the application imports the basic module,
-the basic module selects the proper specific module among the allowable
specific modules,
-the basic module imports the selected module with an __import__ call
equivalent to "import selected_module_X as select_module",
-Any reference to the specific module in the basic module is written in
the form "selected_module.object_name".

Any better solution?
http://peak.telecommunity.com/DevCen...ackage-support

Diez
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.