Confused about namespaces

Discussion in 'Python' started by KvS, Nov 18, 2005.

  1. KvS

    KvS Guest

    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
     
    KvS, Nov 18, 2005
    #1
    1. Advertising

  2. KvS

    Chris Mellon Guest

    On 18 Nov 2005 15:04:23 -0800, KvS <> 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, Nov 18, 2005
    #2
    1. Advertising

  3. KvS

    KvS Guest

    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, Nov 18, 2005
    #3
  4. KvS

    Chris Mellon Guest

    On 18 Nov 2005 15:29:43 -0800, KvS <> 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, Nov 18, 2005
    #4
  5. KvS

    KvS Guest

    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, Nov 19, 2005
    #5
  6. KvS

    Chris Mellon Guest

    On 18 Nov 2005 16:09:44 -0800, KvS <> 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, Nov 19, 2005
    #6
  7. KvS

    KvS Guest

    > 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, Nov 19, 2005
    #7
  8. > 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, Nov 19, 2005
    #8
  9. KvS <> 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, Nov 19, 2005
    #9
  10. 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, Nov 19, 2005
    #10
  11. KvS

    KvS Guest

    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, Nov 19, 2005
    #11
  12. KvS <> 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, Nov 20, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. valentin tihomirov

    namespaces

    valentin tihomirov, May 24, 2004, in forum: VHDL
    Replies:
    0
    Views:
    610
    valentin tihomirov
    May 24, 2004
  2. Craig Deelsnyder

    Best Practices - solution - namespaces - classes

    Craig Deelsnyder, Aug 3, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    436
    Vincent V
    Aug 4, 2003
  3. Will

    Conflicting namespaces??

    Will, Aug 13, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    1,724
    Chris R. Timmons
    Aug 13, 2003
  4. ravi sankar
    Replies:
    2
    Views:
    393
    abdul bari
    Aug 27, 2003
  5. Brian Roberts

    Confused about hasattr/getattr/namespaces

    Brian Roberts, Feb 29, 2004, in forum: Python
    Replies:
    2
    Views:
    313
    Bob Ippolito
    Feb 29, 2004
Loading...

Share This Page