Python modules

Discussion in 'Python' started by zoom, Jan 14, 2013.

  1. zoom

    zoom Guest

    Is there any "rules" regarding importing python modules within your own
    module? I mean, how does this affects the performance of the program?

    For example, I have my own module named "sound".
    At the top of the file sound.py I have:
    import scipy

    In the code I have:
    import scipy, sound, etc

    Now I have two instances of every function within scipy, e.g.
    scipy.r_[a] = sound.scipy.r_[a]

    Module importing is quite fast, but not instant. It takes some time, but
    it happens only once. My concern is whether I hold all these multiple
    instances of same function in the memory, and does this reduce the
    performance of my program.

    In short, when creating a module, is it worthwhile to be careful and
    import only necessary functions, nothing more?
    zoom, Jan 14, 2013
    #1
    1. Advertising

  2. zoom

    zoom Guest

    On 01/14/2013 04:01 PM, Dan Sommers wrote:
    > On Mon, 14 Jan 2013 15:54:27 +0100, zoom wrote:
    >
    >> Is there any "rules" regarding importing python modules within your own
    >> module? I mean, how does this affects the performance of the program?

    >
    > "Even the initializers are optimized!" -- Mel, the real programmer
    >

    Great!

    > Unless you've profiled it, and the extra memory taken up by unused
    > functions or modules is measurable and near the top of the list of
    > performance issues, I wouldn't worry about it.
    >
    >> Now I have two instances of every function within scipy, e.g.
    >> scipy.r_[a] = sound.scipy.r_[a]

    >
    > No: now you have two names for every function within scipy. The
    > functions themselves are not duplicated.
    >
    > Dan


    Now I love Python even more...
    zoom, Jan 14, 2013
    #2
    1. Advertising

  3. On Tue, Jan 15, 2013 at 1:54 AM, zoom <> wrote:
    > Is there any "rules" regarding importing python modules within your own
    > module? I mean, how does this affects the performance of the program?
    >
    > In short, when creating a module, is it worthwhile to be careful and import
    > only necessary functions, nothing more?


    Nope. When you import a module, a record of it is kept in sys.modules,
    so the next time you import it, it's just picking up the same module
    object.

    > scipy.r_[a] = sound.scipy.r_[a]


    They'll actually be the same thing, which you can test with the 'is'
    operator. The performance cost of reimporting a module is very low; in
    fact, trying to avoid it by adorning all your usage with an extra
    dot-level will probably cost you a lot more, since there'll be an
    extra lookup every time.

    Have at it! :)

    ChrisA
    Chris Angelico, Jan 14, 2013
    #3
  4. zoom

    Rick Johnson Guest

    On Monday, January 14, 2013 9:04:00 AM UTC-6, Chris Angelico wrote:
    > The performance cost of reimporting a module is very low;
    > in fact, trying to avoid it by adorning all your usage
    > with an extra dot-level will probably cost you a lot more,
    > since there'll be an extra lookup every time.


    Most people "adorn" a module with an extra dot to:

    1. create a shorter name (f.e.[1] tk instead of Tkinter)

    2. keep their namespace clean.

    Only a fool would do "from Tkinter import *"[2]. A wise programmer, who needed to access many members of Tkinter, would do instead "import Tkinter as tk", and then prepend all members with "tk.".

    [1] Abbr: (F)or (E)xample. (I feel an EnglishWart brewing on this subject!)
    [2] With the exception of command line testing, learning, or playing.
    Rick Johnson, Jan 14, 2013
    #4
  5. zoom

    Rick Johnson Guest

    On Monday, January 14, 2013 9:04:00 AM UTC-6, Chris Angelico wrote:
    > The performance cost of reimporting a module is very low;
    > in fact, trying to avoid it by adorning all your usage
    > with an extra dot-level will probably cost you a lot more,
    > since there'll be an extra lookup every time.


    Most people "adorn" a module with an extra dot to:

    1. create a shorter name (f.e.[1] tk instead of Tkinter)

    2. keep their namespace clean.

    Only a fool would do "from Tkinter import *"[2]. A wise programmer, who needed to access many members of Tkinter, would do instead "import Tkinter as tk", and then prepend all members with "tk.".

    [1] Abbr: (F)or (E)xample. (I feel an EnglishWart brewing on this subject!)
    [2] With the exception of command line testing, learning, or playing.
    Rick Johnson, Jan 14, 2013
    #5
  6. On 2013-01-14, Rick Johnson <> wrote:

    > Only a fool would do "from Tkinter import *"[2].


    > [2] With the exception of command line testing, learning, or playing.


    I don't think those should be excepted. Habits acquired during
    learning/playing will be continue when doing real work, and "Example"
    code provided as part of lessons/tutorials _will_ get copied into real
    programs.

    IMO, tutorials that take shortcuts like "from Tkinter import *" are A
    Bad Thing(tm).

    When teaching somebody how to do something, don't show them the wrong
    way do to something and then after they've learned that add "by the
    way, don't actually do it that way".

    --
    Grant Edwards grant.b.edwards Yow! Your CHEEKS sit like
    at twin NECTARINES above
    gmail.com a MOUTH that knows no
    BOUNDS --
    Grant Edwards, Jan 14, 2013
    #6
    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. Remy Cool
    Replies:
    1
    Views:
    431
    Remy Cool
    Aug 27, 2003
  2. Tobiah
    Replies:
    2
    Views:
    311
    Tobiah
    Sep 14, 2003
  3. Ben Weintraub

    Disabling modules using Modules/Setup

    Ben Weintraub, Sep 9, 2006, in forum: Python
    Replies:
    0
    Views:
    351
    Ben Weintraub
    Sep 9, 2006
  4. Peter Peyman Puk

    Importing v reloading modules modules

    Peter Peyman Puk, Mar 19, 2010, in forum: Python
    Replies:
    0
    Views:
    298
    Peter Peyman Puk
    Mar 19, 2010
  5. ImpalerCore
    Replies:
    0
    Views:
    835
    ImpalerCore
    Mar 10, 2011
Loading...

Share This Page