Confused about namespaces

[KvS]

Hi all,

to start with, excuse me, I'm still learning programming alltogether,
probably I'm making some fundamental mistake here...

I have the files settings.py, GUIclasses.py and main.py in the same
directory. In the file main.py are the statements:

import settings
from GUIclasses import *

class Toepassing(wx.App):
def OnInit(self):
window = KFrame(None, "Testerdetest", (1000,900))
self.SetTopWindow(window)
window.Show(True)
return True

app = Toepassing(None)
app.MainLoop()

In the file GUIclasses.py I have the statements:

import wx
import wx.lib.mixins.listctrl as listmix

class KFrame(wx.Frame):
def __init__(self, parent, title, Size):
...some code...
self.lst = settings.attrLijst
....some more code......

Now if I run the main.py file I get the error:

File "G:\Programmeren\Codes contactenlijst\GUIclasses.py", line 40,
in __init_
_
self.lst = settings.attrLijst
NameError: name 'settings' is not defined

Why is this? Since "from GUIclasses import *" this KFrame is now at
"the lowest" namespace and should therefore be able to make use of any
variables living there, including "settings.*", no?

Thanks in advance!

- Kees

[Chris Mellon]

On 18 Nov 2005 15:04:23 -0800, KvS <ke***********@gmail.com> wrote:

Hi all,

to start with, excuse me, I'm still learning programming alltogether,
probably I'm making some fundamental mistake here...

I have the files settings.py, GUIclasses.py and main.py in the same
directory. In the file main.py are the statements:

import settings
from GUIclasses import *

class Toepassing(wx.App):
def OnInit(self):
window = KFrame(None, "Testerdetest", (1000,900))
self.SetTopWindow(window)
window.Show(True)
return True

app = Toepassing(None)
app.MainLoop()

In the file GUIclasses.py I have the statements:

import wx
import wx.lib.mixins.listctrl as listmix

class KFrame(wx.Frame):
def __init__(self, parent, title, Size):
...some code...
self.lst = settings.attrLijst
....some more code......

Now if I run the main.py file I get the error:

File "G:\Programmeren\Codes contactenlijst\GUIclasses.py", line 40,
in __init_
_
self.lst = settings.attrLijst
NameError: name 'settings' is not defined

Why is this? Since "from GUIclasses import *" this KFrame is now at
"the lowest" namespace and should therefore be able to make use of any
variables living there, including "settings.*", no?

import is not like a C/C++ #include - the code in the imported module
is evaluated in it's own namespace, not in the namespace of the
importing file.

So no, this is expected behavior, and should be solved by importing
settings in GUIclasses.py as well.

You don't need to worry about multiple or redundent imports.

Thanks in advance!

- Kees

--
http://mail.python.org/mailman/listinfo/python-list

[Chris Mellon]

On 18 Nov 2005 15:04:23 -0800, KvS <ke***********@gmail.com> wrote:

Hi all,

to start with, excuse me, I'm still learning programming alltogether,
probably I'm making some fundamental mistake here...

I have the files settings.py, GUIclasses.py and main.py in the same
directory. In the file main.py are the statements:

import settings
from GUIclasses import *

class Toepassing(wx.App):
def OnInit(self):
window = KFrame(None, "Testerdetest", (1000,900))
self.SetTopWindow(window)
window.Show(True)
return True

app = Toepassing(None)
app.MainLoop()

In the file GUIclasses.py I have the statements:

import wx
import wx.lib.mixins.listctrl as listmix

class KFrame(wx.Frame):
def __init__(self, parent, title, Size):
...some code...
self.lst = settings.attrLijst
....some more code......

Now if I run the main.py file I get the error:

File "G:\Programmeren\Codes contactenlijst\GUIclasses.py", line 40,
in __init_
_
self.lst = settings.attrLijst
NameError: name 'settings' is not defined

Why is this? Since "from GUIclasses import *" this KFrame is now at
"the lowest" namespace and should therefore be able to make use of any
variables living there, including "settings.*", no?

import is not like a C/C++ #include - the code in the imported module
is evaluated in it's own namespace, not in the namespace of the
importing file.

So no, this is expected behavior, and should be solved by importing
settings in GUIclasses.py as well.

You don't need to worry about multiple or redundent imports.

Thanks in advance!

- Kees

--
http://mail.python.org/mailman/listinfo/python-list

[KvS]

Ok, makes sense but didn't seem "natural" to me, although it is an
obvious consequence of what you just pointed out, namely that modules
are evaluated in their own namespace, something to keep in mind... On
the other hand it does apparently work recursively "the other way
around" since I didn't explicitly import wx in main.py but only
indirect via importing GUIclasses in which wx is imported right?

Thanks. :).

[KvS]

Ok, makes sense but didn't seem "natural" to me, although it is an
obvious consequence of what you just pointed out, namely that modules
are evaluated in their own namespace, something to keep in mind... On
the other hand it does apparently work recursively "the other way
around" since I didn't explicitly import wx in main.py but only
indirect via importing GUIclasses in which wx is imported right?

Thanks. :).

[Chris Mellon]

On 18 Nov 2005 15:29:43 -0800, KvS <ke***********@gmail.com> wrote:

Ok, makes sense but didn't seem "natural" to me, although it is an
obvious consequence of what you just pointed out, namely that modules
are evaluated in their own namespace, something to keep in mind... On
the other hand it does apparently work recursively "the other way
around" since I didn't explicitly import wx in main.py but only
indirect via importing GUIclasses in which wx is imported right?

it worked because all the code that used stuff from the wx namespace
was in GUIclasses.py. If you tried to use create wx classes directly
in your toplevel file it would fail unless you did an "import wx"
first.

Now, as a slight consequence of the specific way you imported, it may
appear to do something different - when GUIClasses.py imported wx, an
entry in the modules namespace was created with the value "wx", and
the value being the wx module. When you do "from GUIClasses import *",
that imports all the symbols in GUIClasses namespace into your local
namespace, including the "wx" entry. This kind of cascading behavior
is one reason that "from foo import *" is frowned up, because the
namespace pollution can cause confusing bugs.
Thanks. :).

--
http://mail.python.org/mailman/listinfo/python-list

[Chris Mellon]

On 18 Nov 2005 15:29:43 -0800, KvS <ke***********@gmail.com> wrote:

Ok, makes sense but didn't seem "natural" to me, although it is an
obvious consequence of what you just pointed out, namely that modules
are evaluated in their own namespace, something to keep in mind... On
the other hand it does apparently work recursively "the other way
around" since I didn't explicitly import wx in main.py but only
indirect via importing GUIclasses in which wx is imported right?

it worked because all the code that used stuff from the wx namespace
was in GUIclasses.py. If you tried to use create wx classes directly
in your toplevel file it would fail unless you did an "import wx"
first.

Now, as a slight consequence of the specific way you imported, it may
appear to do something different - when GUIClasses.py imported wx, an
entry in the modules namespace was created with the value "wx", and
the value being the wx module. When you do "from GUIClasses import *",
that imports all the symbols in GUIClasses namespace into your local
namespace, including the "wx" entry. This kind of cascading behavior
is one reason that "from foo import *" is frowned up, because the
namespace pollution can cause confusing bugs.
Thanks. :).

--
http://mail.python.org/mailman/listinfo/python-list

[KvS]

Hmm. But actually I was doing this import from GUIclasses with exactly
this in mind, namely that it would make wx also available at top level.
I (in my naive understanding) see this as "natural" and actually
desirable, how could this cause confusing bugs? Do you mean multiple
"from ... import *"'s 'on top of each other' would cause foo1.foo2.attr
and foo1.attr both would become just attr and therefore ambiguous at
top level?

If you import foo in two different modules, does the interpreter then
create one instance of foo and create a reference in both modules to
the same foo rather than creating two different instances of foo?

[KvS]

Hmm. But actually I was doing this import from GUIclasses with exactly
this in mind, namely that it would make wx also available at top level.
I (in my naive understanding) see this as "natural" and actually
desirable, how could this cause confusing bugs? Do you mean multiple
"from ... import *"'s 'on top of each other' would cause foo1.foo2.attr
and foo1.attr both would become just attr and therefore ambiguous at
top level?

If you import foo in two different modules, does the interpreter then
create one instance of foo and create a reference in both modules to
the same foo rather than creating two different instances of foo?

[Chris Mellon]

On 18 Nov 2005 16:09:44 -0800, KvS <ke***********@gmail.com> wrote:

Hmm. But actually I was doing this import from GUIclasses with exactly
this in mind, namely that it would make wx also available at top level.
There's no reason not to just "import wx" if you want that.
I (in my naive understanding) see this as "natural" and actually
desirable, how could this cause confusing bugs? Do you mean multiple
"from ... import *"'s 'on top of each other' would cause foo1.foo2.attr
and foo1.attr both would become just attr and therefore ambiguous at
top level?
the second import will overwrite the first, making the first inaccessible

If you import foo in two different modules, does the interpreter then
create one instance of foo and create a reference in both modules to
the same foo rather than creating two different instances of foo?

No. It creates the foos within each module, but which foo you have
access to in the importing module is determined by the order of
import.
--
http://mail.python.org/mailman/listinfo/python-list

[Chris Mellon]

On 18 Nov 2005 16:09:44 -0800, KvS <ke***********@gmail.com> wrote:

Hmm. But actually I was doing this import from GUIclasses with exactly
this in mind, namely that it would make wx also available at top level.
There's no reason not to just "import wx" if you want that.
I (in my naive understanding) see this as "natural" and actually
desirable, how could this cause confusing bugs? Do you mean multiple
"from ... import *"'s 'on top of each other' would cause foo1.foo2.attr
and foo1.attr both would become just attr and therefore ambiguous at
top level?
the second import will overwrite the first, making the first inaccessible

If you import foo in two different modules, does the interpreter then
create one instance of foo and create a reference in both modules to
the same foo rather than creating two different instances of foo?

No. It creates the foos within each module, but which foo you have
access to in the importing module is determined by the order of
import.
--
http://mail.python.org/mailman/listinfo/python-list

[KvS]

> There's no reason not to just "import wx" if you want that.

Yes, that's clear. But if you would make some huge application that has
a large number of nested modules, each importing the former one, then
avoiding the use of "from ... import *" would mean that you have to use
long references like foo1.foo2.... to get to the lowest modules plus
that you'd have to check each module for imports outside this tree.

If you would use "from ... import *" (except at top level) you have to
be aware of overriding, but you can also use this to your advantage and
any foo1.attr reference would just work right, without further ado...
Or would in such a case a class hierarchy be the thing to use?

No. It creates the foos within each module, but which foo you have
access to in the importing module is determined by the order of
import.

Am I understanding correctly that if you have a module foo importing wx
and a module main importing both foo and wx there are actually two
instances of wx created, one referenced to by (at top level) foo.wx.*
and one wx.*? If this is indeed the case it isn't too good for the
performance doing this importing of wx multiple times right?

- Kees

[KvS]

> There's no reason not to just "import wx" if you want that.

Yes, that's clear. But if you would make some huge application that has
a large number of nested modules, each importing the former one, then
avoiding the use of "from ... import *" would mean that you have to use
long references like foo1.foo2.... to get to the lowest modules plus
that you'd have to check each module for imports outside this tree.

If you would use "from ... import *" (except at top level) you have to
be aware of overriding, but you can also use this to your advantage and
any foo1.attr reference would just work right, without further ado...
Or would in such a case a class hierarchy be the thing to use?

No. It creates the foos within each module, but which foo you have
access to in the importing module is determined by the order of
import.

Am I understanding correctly that if you have a module foo importing wx
and a module main importing both foo and wx there are actually two
instances of wx created, one referenced to by (at top level) foo.wx.*
and one wx.*? If this is indeed the case it isn't too good for the
performance doing this importing of wx multiple times right?

- Kees

[Diez B. Roggisch]

> Am I understanding correctly that if you have a module foo importing wx

and a module main importing both foo and wx there are actually two
instances of wx created, one referenced to by (at top level) foo.wx.*
and one wx.*? If this is indeed the case it isn't too good for the
performance doing this importing of wx multiple times right?

No, they aren't two instances. The first import will evaluate the
wx-module (there could be code in there executed upon importing it). All
subsequent imports of that module will only bind the already imported
module to the name.

So - the way to have one module be available in several other modules is
to import them in each of them - causing actually close to none
overhead, as the import statement is evaluated only once per file
(unless you put it in a loop or something, but this still only would
return the same reference.)

Regards,

Diez

[Diez B. Roggisch]

> Am I understanding correctly that if you have a module foo importing wx

and a module main importing both foo and wx there are actually two
instances of wx created, one referenced to by (at top level) foo.wx.*
and one wx.*? If this is indeed the case it isn't too good for the
performance doing this importing of wx multiple times right?

No, they aren't two instances. The first import will evaluate the
wx-module (there could be code in there executed upon importing it). All
subsequent imports of that module will only bind the already imported
module to the name.

So - the way to have one module be available in several other modules is
to import them in each of them - causing actually close to none
overhead, as the import statement is evaluated only once per file
(unless you put it in a loop or something, but this still only would
return the same reference.)

Regards,

Diez

[Alex Martelli]

KvS <ke***********@gmail.com> wrote:

There's no reason not to just "import wx" if you want that.
Yes, that's clear. But if you would make some huge application that has
a large number of nested modules, each importing the former one, then
avoiding the use of "from ... import *" would mean that you have to use
long references like foo1.foo2.... to get to the lowest modules plus

Not at all -- you may perfectly well "import a.b.c.d as e" and use e as
the reference throughout the importing module.

But the point is, modules should be MODULAR (duh) -- if I 'import x' I
should NOT rely on what x itself imports (and so on transitively), just
on what x ``exports'', so to speak, at its TOP level. The Law of
Demeter in its simplified form "if you have more than one dot in your
reference you're doing things wrong" applies. In fact, the many-dots
form of module naming is intended for nested PACKAGES, *NOT* for
"modules which import each other".
that you'd have to check each module for imports outside this tree.

Why would you have to check any module for such "outside imports"? I
don't see the need for any checks.
If you just simply forget the very _existence_ of "from X import *",
your Python code can only grow better as a result. I earnestly hope it
disappears come Python 3.0 time...
Alex

[Alex Martelli]

KvS <ke***********@gmail.com> wrote:

There's no reason not to just "import wx" if you want that.
Yes, that's clear. But if you would make some huge application that has
a large number of nested modules, each importing the former one, then
avoiding the use of "from ... import *" would mean that you have to use
long references like foo1.foo2.... to get to the lowest modules plus

Not at all -- you may perfectly well "import a.b.c.d as e" and use e as
the reference throughout the importing module.

But the point is, modules should be MODULAR (duh) -- if I 'import x' I
should NOT rely on what x itself imports (and so on transitively), just
on what x ``exports'', so to speak, at its TOP level. The Law of
Demeter in its simplified form "if you have more than one dot in your
reference you're doing things wrong" applies. In fact, the many-dots
form of module naming is intended for nested PACKAGES, *NOT* for
"modules which import each other".
that you'd have to check each module for imports outside this tree.

Why would you have to check any module for such "outside imports"? I
don't see the need for any checks.
If you just simply forget the very _existence_ of "from X import *",
your Python code can only grow better as a result. I earnestly hope it
disappears come Python 3.0 time...
Alex

[Bruno Desthuilliers]

KvS a écrit :

Ok, makes sense but didn't seem "natural" to me,
It will seem more natural if you understand that modules should be
modulars (ie: low coupling, high cohesion). A module should *never*
bother about no rely upon other modules being imported by the module it
imports itself. Err, not quite clear... Let's rephrase it : a module
should only used symbols it defines itself or that it *explicitely*
imports from other modules.
although it is an
obvious consequence of what you just pointed out, namely that modules
are evaluated in their own namespace, something to keep in mind... On
the other hand it does apparently work recursively "the other way
around" since I didn't explicitly import wx in main.py but only
indirect via importing GUIclasses in which wx is imported right?

You've already got technical answers to this - please carefully (re)read
Alex Martelli's post.

Now about coding style: this is *very* Bad Style(tm). Your main module
imports should look like this:

import wx
# import settings -> we don't use the settings module here
from GUIclasses import KFrame

(...)

and the GUIclasses module's import :

import wx
import wx.lib.mixins.listctrl as listmix
import settings -> *here* we use the settings module

(...)

Python's philosophy is to favour readability.

Talking about imports, take time to open your Python interactive shell
and type "import this" !-)

[Bruno Desthuilliers]

KvS a écrit :

Ok, makes sense but didn't seem "natural" to me,
It will seem more natural if you understand that modules should be
modulars (ie: low coupling, high cohesion). A module should *never*
bother about no rely upon other modules being imported by the module it
imports itself. Err, not quite clear... Let's rephrase it : a module
should only used symbols it defines itself or that it *explicitely*
imports from other modules.
although it is an
obvious consequence of what you just pointed out, namely that modules
are evaluated in their own namespace, something to keep in mind... On
the other hand it does apparently work recursively "the other way
around" since I didn't explicitly import wx in main.py but only
indirect via importing GUIclasses in which wx is imported right?

You've already got technical answers to this - please carefully (re)read
Alex Martelli's post.

Now about coding style: this is *very* Bad Style(tm). Your main module
imports should look like this:

import wx
# import settings -> we don't use the settings module here
from GUIclasses import KFrame

(...)

and the GUIclasses module's import :

import wx
import wx.lib.mixins.listctrl as listmix
import settings -> *here* we use the settings module

(...)

Python's philosophy is to favour readability.

Talking about imports, take time to open your Python interactive shell
and type "import this" !-)

[KvS]

Thanks a lot for all the answers. After rereading everything said here
today it's become more clear to me what you guys are telling me and
I'll actively try to forget about "from ... import *" ;).

[KvS]

Thanks a lot for all the answers. After rereading everything said here
today it's become more clear to me what you guys are telling me and
I'll actively try to forget about "from ... import *" ;).

[Alex Martelli]

KvS <ke***********@gmail.com> wrote:

Thanks a lot for all the answers. After rereading everything said here
today it's become more clear to me what you guys are telling me and
I'll actively try to forget about "from ... import *" ;).

I commend you for your decision. It's a construct that I sometimes find
quite handy in an experimentation session in the interactive
interpreter, but just has no really good place in 'true' code;-0.
Alex

[Alex Martelli]

KvS <ke***********@gmail.com> wrote:

Thanks a lot for all the answers. After rereading everything said here
today it's become more clear to me what you guys are telling me and
I'll actively try to forget about "from ... import *" ;).

I commend you for your decision. It's a construct that I sometimes find
quite handy in an experimentation session in the interactive
interpreter, but just has no really good place in 'true' code;-0.
Alex