Namespaces, classes, and using standard modules

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Dan Rawson
    #1

    Namespaces, classes, and using standard modules

    I have several simple classes which need to us "standard" modules like os and sys

    A class might look like:

    # --------- MyClass.py -----------------------
    class MyClass:
    def __init__ (self):
    self.data = ''
    self.data2 = 'mydata'

    def show (self):
    print "Data is " + self.data
    print "Other data is " + self.data2
    print "Directory is " + os.getcwd()
    # --------------------------------------------


    If I do:
    [color=blue][color=green][color=darkred]
    >>> import os
    >>> from MyClass import MyClass
    >>> x = MyClass()
    >>> x.show()[/color][/color][/color]

    it fails with

    NameError: global name 'os' is not defined

    However, if I put the 'import os' statement in MyClass.py, but OUTSIDE the class definition, it works fine. I can also
    (obviously) put the import inside the class definition, then use 'self.os.getcwd ()' but that seems to me to be
    needlessly complicated.

    I would have expected that importing os from the interactive prompt would have worked, and that the 'import os'
    statement in MyClass.py would have been ignored.

    Any comments or clues about how this SHOULD work would be appreciated!

    TIA . . . .

    Dan

    Tags: None
    • Fredrik Lundh
      #2
      Re: Namespaces, classes, and using standard modules

      Dan Rawson wrote:
      [color=blue]
      > I would have expected that importing os from the interactive prompt
      > would have worked, and that the 'import os' statement in MyClass.py
      > would have been ignored.[/color]

      every module has its own namespace.
      [color=blue]
      > Any comments or clues about how this SHOULD work would be appreciated![/color]

      the manual is a good place to start:

      Welcome to Python.org
      http://www.python.org/doc/current/tut/node8.html#SECTION008100000000000000000
      The official home of the Python Programming Language

      Welcome to Python.org
      http://www.python.org/doc/current/ref/naming.html
      The official home of the Python Programming Language


      </F>




        Comment

        • Dan Rawson
          #3
          Re: Namespaces, classes, and using standard modules

          Fredrik Lundh wrote:[color=blue]
          > Dan Rawson wrote:
          >
          >[color=green]
          >>I would have expected that importing os from the interactive prompt
          >>would have worked, and that the 'import os' statement in MyClass.py
          >>would have been ignored.[/color]
          >
          >
          > every module has its own namespace.
          >
          >[color=green]
          >>Any comments or clues about how this SHOULD work would be appreciated![/color]
          >
          >
          > the manual is a good place to start:
          >
          > http://www.python.org/doc/current/tu...00000000000000
          > http://www.python.org/doc/current/ref/naming.html
          >[/color]
          Hmm . . . I'm still a bit confused . . . The naming doc says that

          from MyClass import MyClass

          will only import the stuff that is part of the class scope (if I read it correctly). But it appears to also read and
          use the 'import os' at the module level for the MyClass.py file.

          The second question is why "import os" doesn't work at the interactive prompt; once I say that, isn't that a 'global' ??

          Thanks!

          Dan

            Comment

            • Andrew Dalke
              #4
              Re: Namespaces, classes, and using standard modules

              Dan Rawson[color=blue]
              > Hmm . . . I'm still a bit confused . . . The naming doc says that
              >
              > from MyClass import MyClass
              >
              > will only import the stuff that is part of the class scope (if I read it[/color]
              correctly). But it[color=blue]
              > appears to also read and use the 'import os' at the module level for the[/color]
              MyClass.py file.[color=blue]
              >
              > The second question is why "import os" doesn't work at the interactive[/color]
              prompt; once[color=blue]
              > I say that, isn't that a 'global' ??[/color]

              Every module has its own namespace. The interactive prompt has its own
              namespace, called "__main__". This is not the global namespace. (There is
              a 'global' namespace called "__builtin_ _", but you should almost never put
              anything into it because doing so most often indicates 'bad', or at least
              non-standard/non-Pythonic programming style.)

              All code in a module looks for so-called globals only in the module's
              namespace
              and, failing that, in the __builtin__ namespace. So your
              MyClass.MyClass .show
              method looks for 'os' first in the MyClass module and then in the
              __builtin__,
              finding it in neither.

              This is what's often called "static scoping," as compared to "dynamic
              scoping,"
              which is what you are looking for. That wouldn't lead to easy to use code
              because then when you import a class or function you would need to also
              import all the modules it uses. I sure don't want to remember all those.

              Andrew
              dalke@dalkescie ntific.com


                Comment

                Previous template Next
                Working...