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.A pp):
def OnInit(self):
window = KFrame(None, "Testerdete st", (1000,900))
self.SetTopWind ow(window)
window.Show(Tru e)
return True

app = Toepassing(None )
app.MainLoop()

In the file GUIclasses.py I have the statements:

import wx
import wx.lib.mixins.l istctrl as listmix

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

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

File "G:\Programmere n\Codes contactenlijst\ GUIclasses.py", line 40,
in __init_
_
self.lst = settings.attrLi jst
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.A pp):
def OnInit(self):
window = KFrame(None, "Testerdete st", (1000,900))
self.SetTopWind ow(window)
window.Show(Tru e)
return True

app = Toepassing(None )
app.MainLoop()

In the file GUIclasses.py I have the statements:

import wx
import wx.lib.mixins.l istctrl as listmix

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

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

File "G:\Programmere n\Codes contactenlijst\ GUIclasses.py", line 40,
in __init_
_
self.lst = settings.attrLi jst
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.A pp):
def OnInit(self):
window = KFrame(None, "Testerdete st", (1000,900))
self.SetTopWind ow(window)
window.Show(Tru e)
return True

app = Toepassing(None )
app.MainLoop()

In the file GUIclasses.py I have the statements:

import wx
import wx.lib.mixins.l istctrl as listmix

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

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

File "G:\Programmere n\Codes contactenlijst\ GUIclasses.py", line 40,
in __init_
_
self.lst = settings.attrLi jst
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