Importing modules

Discussion in 'Python' started by qwweeeit@yahoo.it, May 11, 2005.

  1. Guest

    The pythonic way of programming requires, as far as I know, to spread a
    big application in plenty of more manageable scripts, using import or
    from ... import to connect the various modules.
    In some cases there is a further complication: module importing through
    an indirect mechanism, like: exec "from " + xxx + " import *".

    A part the fact that I have not understood the "real" difference
    between import and from ... import (or also from... import *), is it
    possible to re-build the application in only one chunck?
    This is only to better understand the application's structure, in order
    to implement a flow chart tool.

    I have already developed a cross reference tool and I applied it to
    PySol (solitary card games). PySol is made up of almost 100 modules for
    a total of almost 30000 lines.
    To understand a program, however, you need also a flow chart...
    , May 11, 2005
    #1
    1. Advertising

  2. wrote:

    > To understand a program, however, you need also a flow chart...


    so understand a carefully designed modular component structure, you
    have to remove the structure so you can create a flow chart?

    did you perhaps stumble upon a strange man with a keg of liquor back
    in the sixties, or what's going on here? ;-)

    </F>
    Fredrik Lundh, May 11, 2005
    #2
    1. Advertising

  3. wrote:
    [...]
    > In some cases there is a further complication: module importing

    through
    > an indirect mechanism, like: exec "from " + xxx + " import *".


    Don't do that. Please ;). If you need too import some modules based
    on the module name, stored in a string, consider the using __import__
    (http://www.python.org/doc/2.4/lib/built-in-funcs.html). It's a bit
    tricky but you may define your own help functions on top of it.

    > A part the fact that I have not understood the "real" difference
    > between import and from ... import (or also from... import *),



    >>> a = exp(1.0) # does not work


    >>> import math
    >>> e = math.exp(1.0)# works
    >>> e = exp(1.0) # does not work


    >>> from math import exp
    >>> e = exp(1.0) # works


    >>> from math import *
    >>> e = exp(1.0) # works
    >>> o = sqrt(1.0) # works too


    > is it
    > possible to re-build the application in only one chunck?
    > This is only to better understand the application's structure, in

    order
    > to implement a flow chart tool.


    uh ?
    =?iso-8859-1?q?S=E9bastien_Boisg=E9rault?=, May 11, 2005
    #3
  4. "Fredrik Lundh" wrote :

    > wrote:
    >
    > > To understand a program, however, you need also a flow chart...

    >
    > so understand a carefully designed modular component structure, you
    > have to remove the structure so you can create a flow chart?
    >
    > did you perhaps stumble upon a strange man with a keg of liquor back
    > in the sixties, or what's going on here? ;-)
    >
    > </F>
    >
    >
    >


    In more modern terminology, an analog might be UML sequence diagrams.

    George
    George Sakkis, May 11, 2005
    #4
  5. Guest

    Fredrik Lundh ha scritto:
    > wrote:
    >
    > > To understand a program, however, you need also a flow chart...

    >
    > so understand a carefully designed modular component structure, you
    > have to remove the structure so you can create a flow chart?


    Not everyone is a "guru" like you... I already implemented (some years
    ago) flow chart tools but for structured languages, not Object Oriented
    ones like Python.
    So forgive me if I'm in trouble... Instead of mocking me, the better
    should be to give me an brief idea of the import's roll (namespaces,
    visibility and so on...)

    Bye.
    , May 11, 2005
    #5
  6. Steve Holden Guest

    wrote:
    > Fredrik Lundh ha scritto:
    >
    >> wrote:
    >>
    >>
    >>>To understand a program, however, you need also a flow chart...

    >>
    >>so understand a carefully designed modular component structure, you
    >>have to remove the structure so you can create a flow chart?

    >
    >
    > Not everyone is a "guru" like you... I already implemented (some years
    > ago) flow chart tools but for structured languages, not Object Oriented
    > ones like Python.
    > So forgive me if I'm in trouble... Instead of mocking me, the better
    > should be to give me an brief idea of the import's roll (namespaces,
    > visibility and so on...)
    >
    > Bye.
    >

    Please forgive the effbot, which has been in need of lubrication for
    some time. I am happy to say that he will be offline for three minutes
    and forty-six seconds tomorrow at 0945 UTC, after which we expect that
    advice will be dispensed in a rather more dispassionate fashion.
    According to the research team an effort to engender empathy in the
    bot's behavior and thus make it more acceptable to a majority of the
    Python community was found to conflict with the "can't teach an old dog
    new tricks" circuitry that inherently limits the expansion capability of
    all the early generation bots.

    In round terms you might say that

    import module

    brings the named module into the current name space as a dependent name
    space. Since the module is accessible by its name (in this case
    "module"), names defined inside the module (normally, remember, only
    executed once the first time it is imported) are available from the
    importing module by qualifying the name of the desired value with the
    name of the imported module. Hence

    module.func(2, 3, 4)

    calls the function func defined in module with three numeric arguments.

    name = module.a

    binds the name "name" in the local namespace to the same value currently
    referenced by the name "a" in "module".

    On the other hand,

    from module import func, a

    takes the names "func" and "a" bound (we hope) when the module was
    executed on first import and binds the same names to the same values in
    the current (importing) module's name space.

    The usual (Python) rules for binding apply: when several names are bound
    to the same mutable value all bindings reference the same object, and a
    change to the referenced mutable object is seen no matter which binding
    is used to access that value.

    Rebinding of a name from an immutable value means it no longer
    references the same object it formerly did.

    regards
    Steve
    --
    Steve Holden +1 703 861 4237 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Steve Holden, May 12, 2005
    #6
  7. Mike Meyer Guest

    writes:

    > A part the fact that I have not understood the "real" difference
    > between import and from ... import (or also from... import *), is it
    > possible to re-build the application in only one chunck?
    > This is only to better understand the application's structure, in order
    > to implement a flow chart tool.


    "import foo" creates foo in the current namespace. It'll be a module.

    "from foo import bar" creates bar from the foo module in the current
    namespace. It's type will be the same as it is in foo. Note that
    assigning to bar in the current namespace after doing this import
    *will not* change bar in foo.

    > I have already developed a cross reference tool and I applied it to
    > PySol (solitary card games). PySol is made up of almost 100 modules for
    > a total of almost 30000 lines.
    > To understand a program, however, you need also a flow chart...


    *You* may need a flowchart. Lots of people don't. The last time I had
    to document a program graphically, I used something other than
    flowcharts (I've since forgotten the name, but could provide examples
    on demand). Such tools are really only useful for describing a single
    function. To understand the relationship between
    functions/methods/etc., you really need other tools. UML is probably
    the most used such tool in the OO world.

    To understand a program, you need to understand the communications
    channels between the components. Mashing all the components together
    into one namespace destroys the very information you need to properly
    understand the program. BON is a nice format for documenting such
    things, but it's really aimed at a more pure OO environment than
    Python provides.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
    Mike Meyer, May 12, 2005
    #7
  8. Guest

    Hi all.

    Steve Holden wrote:
    >
    > ... to conflict with the "can't teach an old dog new tricks" ...


    Excuse my English (also some terms of your replay have no
    correspondance in my English dictionary...) and my lack of patience
    (beeing an "old dog" ...).

    My original request was mainly centered on flow chart and "import"
    interfered with "my" understanding of an application.

    By the way, (replaying to Sébastien Boisgérault) of course I don't
    use indirect import of any sort (it's too tricky for me...).

    The only constructive comments was that of George Sakkis on using UML
    sequence diagrams.
    Also Mike Meyer points me in the same direction (with more arguments
    and ... warnings).

    I will stick with their advice: I will abandon my project of
    implementing a flow chart tool...

    A last word of reconciliation: I must thank the expert group for their
    valuable activity especially towards the newbies like me...

    Regards.
    , May 12, 2005
    #8
  9. wrote:

    > So forgive me if I'm in trouble... Instead of mocking me, the better
    > should be to give me an brief idea of the import's roll (namespaces,
    > visibility and so on...)


    if you're interested in learning stuff, why not spend your time reading
    up on how things work, rather than bragging about how you won't use
    classes, etc, and posting silly assertions.

    there are plenty of information on python.org; if you get stuck on some
    specific part of it, there are lots of people here than can help you sort
    things out. but if you don't even want to try, all you're doing is wasting
    time -- your own, and others.

    </F>
    Fredrik Lundh, May 12, 2005
    #9
  10. Guest

    Hi Fredrik,
    thank you for saying that I am
    > ... posting silly assertions.

    I didn't born " Python expert", and I am hardly trying to learn
    something.
    I don't like classes but this assertion (silly... I agree) is due to
    the fact that "I don't understand them well" (I hope to change mind in
    a near future).
    Another item (for me...) difficult, is "import modules", and "plenty of
    information" (as you said) does not help me much: the mechanism of
    variable visibility and namespaces is not clear to me. It will be
    enough an example of the various type of imports and they difference in
    terms of namespaces or, better, of something you can see on your
    monitor, or print like, for example, a dictionary.
    As you can see from my replay to Steve Holden, I have abandoned my
    project on flowcharting. I must study (as you adviced me)...
    Bye.
    , May 12, 2005
    #10
  11. Fredrik Lundh, May 12, 2005
    #11
  12. Guest

    Hi Fredrik,
    thank you very much for your articles (especially that on
    import-confusion). At last I grasped, also if not thorougly, the import
    mechanism. What cleared my doubts was your recursive import paragraph.
    In the Guido's "Python Reference Manual" he says:
    "Import statements are executed in two steps: (1) find a module , and
    initialize it if necessary..."
    ....almost like it was not necessary to go through it executing it (and
    initializing the classes if necessary).
    I made a small script to be sure and (...of course) confirmed what you
    said...
    I have still some doubts on the namespaces and functions/variables
    visibility, but for that there is the error mechanism...
    Bye.
    , May 13, 2005
    #12
  13. Guest

    CONTEXT:
    Trying to modularize (is this english?) application development : MVC
    style, team distributed so that a visual component can be in one module
    imported and used by the __main__, and connected (read packed) at
    runtime to other components coming from the main or other modules.

    PROBLEM:
    After reading the above reference (and the Nutshell chapter) and trying
    different importing variations I still have a very difficult time
    understanding this situation.
    1-importing Tkinter in main,
    2-importing module that uses Tkinter, without importing Tkinter in that
    module (DOES NOT WORK)
    KLUDGED SOLUTION:
    import Tkinter in module (but don't understand why it has to be this
    way)

    MODEL (I taught would work):
    ## importTestMain module
    from Tkinter import *
    import testModule

    tata = testModule.toto() ## this works
    myWidget = tata.createNewFrame() ## this gets the exception (see below)
    ....

    ## testModule
    class toto(object):
    def __init__(self):
    self.someAttribute= 2
    def createNewFrame(self):
    self.myFrame = Frame() ## culprit line in exception
    return f

    if __main__=='__name__': ## team member tests is work here (does
    work!)
    from Tkinter import *
    myInstance = otherModule.toto()
    myWidget = myInstance.createNewFrame()
    root=Tk()
    myWidget.pack(in_=root)
    root.mainloop()

    The exception says :
    Traceback (most recent call last):
    File
    "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py",
    line 310, in RunScript
    exec codeObject in __main__.__dict__
    File
    "C:\jean_marc\exemples_code_source\modules_packages\import_test\importTestMain.py",
    line 18, in ?
    tata=toto()
    File
    "C:\jean_marc\exemples_code_source\modules_packages\import_test\importTestMain.py",
    line 10, in __init__
    self.myNewFrame =
    self.myTestModuleObject.createNewFrame(self.myInterModuleTestCommand)
    File
    "C:\jean_marc\exemples_code_source\modules_packages\import_test\testModule.py",
    line 8, in createNewFrame
    self.myFrame = Frame()
    NameError: global name 'Frame' is not defined
    >>>


    VARIATION
    Imported testModule AFTER using Tkinter in main... same error :(
    , May 14, 2005
    #13
    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. OKB (not okblacke)

    Importing/reloading modules

    OKB (not okblacke), Sep 4, 2003, in forum: Python
    Replies:
    0
    Views:
    288
    OKB (not okblacke)
    Sep 4, 2003
  2. Tobiah
    Replies:
    2
    Views:
    306
    Tobiah
    Sep 14, 2003
  3. Dave
    Replies:
    2
    Views:
    463
  4. plb
    Replies:
    2
    Views:
    341
  5. Peter Peyman Puk

    Importing v reloading modules modules

    Peter Peyman Puk, Mar 19, 2010, in forum: Python
    Replies:
    0
    Views:
    291
    Peter Peyman Puk
    Mar 19, 2010
Loading...

Share This Page