Where to import modules?

Discussion in 'Python' started by Andreas Neudecker, Sep 26, 2003.

  1. Hi.

    I have a "style" question: Sometimes, modules will only be used in a
    particular, optional, part of a program (function, class), that will not
    always be used when the application is run. So I think it is better to
    import them only there, not on the top of the file (together with the
    other imports). Is that okay, or are there good reasons for not doing so?

    Regards

    Andreas
    Andreas Neudecker, Sep 26, 2003
    #1
    1. Advertising

  2. Andreas Neudecker wrote:
    > Hi.
    >
    > I have a "style" question: Sometimes, modules will only be used in a
    > particular, optional, part of a program (function, class), that will not
    > always be used when the application is run. So I think it is better to
    > import them only there, not on the top of the file (together with the
    > other imports). Is that okay, or are there good reasons for not doing so?


    That's perfectly ok, if you want/need to optimize your program startup
    time. It might also save a byte or two of memory, depending on how large
    the module is.

    -- Gerhard
    =?ISO-8859-1?Q?Gerhard_H=E4ring?=, Sep 26, 2003
    #2
    1. Advertising

  3. Andreas Neudecker

    Peter Hansen Guest

    Andreas Neudecker wrote:
    >
    > I have a "style" question: Sometimes, modules will only be used in a
    > particular, optional, part of a program (function, class), that will not
    > always be used when the application is run. So I think it is better to
    > import them only there, not on the top of the file (together with the
    > other imports). Is that okay, or are there good reasons for not doing so?


    There are not *strong* reasons for avoiding the delayed-import style,
    although clearly maintainability can be affected. It makes it somewhat
    harder for a maintainer to see that a given module is used at all.

    I would not bother putting imports that are rarely used in only the
    functions which need them *unless* I had a really large module which
    took a long time to import and I was actually having problems with
    startup time for the application.

    Basically doing this is an optimization, and you shouldn't be optimizing
    before the program is working, and you shouldn't be optimizing without
    a real need for it. (That is, just because it's a little faster doesn't
    mean it's worth doing.)

    -Peter
    Peter Hansen, Sep 26, 2003
    #3
  4. Andreas Neudecker

    JCM Guest

    Peter Hansen <> wrote:
    ....

    > Basically doing this is an optimization, and you shouldn't be optimizing
    > before the program is working, and you shouldn't be optimizing without
    > a real need for it. (That is, just because it's a little faster doesn't
    > mean it's worth doing.)


    Aside from being an optimization, it's also good for documentation.
    If you see an import at the top of a file it might not be immediately
    clear how or why the module is being used. It's similar reasoning to
    why you might define variables in the narrowest scope posible.
    JCM, Sep 26, 2003
    #4
  5. Andreas Neudecker

    John Roth Guest

    "JCM" <> wrote in message
    news:bl1f7t$oig$...
    > Peter Hansen <> wrote:
    > ...
    >
    > > Basically doing this is an optimization, and you shouldn't be optimizing
    > > before the program is working, and you shouldn't be optimizing without
    > > a real need for it. (That is, just because it's a little faster doesn't
    > > mean it's worth doing.)

    >
    > Aside from being an optimization, it's also good for documentation.
    > If you see an import at the top of a file it might not be immediately
    > clear how or why the module is being used. It's similar reasoning to
    > why you might define variables in the narrowest scope posible.


    There are also reasons having to do with circular imports that
    you might not want to import at the top. However, this situation
    is hazardous enough that some effort in removing the circularity
    is usually warranted.

    In general, I agree with the style guide: put them at the top
    of the module unless there is a real, strong reason to put
    them somewhere else. Even then, I'd put a comment in
    with the main imports pointing out where the embedded
    import exists.

    John Roth
    John Roth, Sep 26, 2003
    #5
  6. Andreas Neudecker

    Peter Hansen Guest

    JCM wrote:
    >
    > Peter Hansen <> wrote:
    > ...
    >
    > > Basically doing this is an optimization, and you shouldn't be optimizing
    > > before the program is working, and you shouldn't be optimizing without
    > > a real need for it. (That is, just because it's a little faster doesn't
    > > mean it's worth doing.)

    >
    > Aside from being an optimization, it's also good for documentation.
    > If you see an import at the top of a file it might not be immediately
    > clear how or why the module is being used. It's similar reasoning to
    > why you might define variables in the narrowest scope posible.


    I'm not sure it's necessarily any clearer when you put the import
    somewhere down in the file, effectively hiding it from casual viewing.

    At the top, it's at least clear that the module *is* imported. If
    you care how it's used, a simple search for "module." will show all
    the places where it's used.

    In the middle of code somewhere, you can clearly see how it's being
    used only if you're actually looking at that exact line.

    John Roth has the right approach: whatever you do, a comment up
    at the top with the others would go a long way towards appeasing
    any concerns about maintainability. Unfortunately, that does mean
    there's isolated duplication (the import, somewhere below, plus the
    comment at the top) and therefore another, though perhaps lesser,
    maintainability problem.

    -Peter
    Peter Hansen, Sep 26, 2003
    #6
  7. Hi.

    Thank you for your opinions!

    Good to look at it from different sides.
    So I think one could sum it all up as:

    - Best place for importing modules is at the top of the file.
    - if optimisation requires or programmer desires to import specific
    modules somewhere else, it is a good idea to add a comment at the top,
    where all the other modules are imported.
    - for optimasation importing inside modules/functions will only make
    sense if loading the module takes time (try rpy, the wrapper for R!) and
    is not used every time the program runs.

    I liked Peter Hansen's remark on optimasation:
    "Basically doing this is an optimization, and you shouldn't be
    optimizing before the program is working, and you shouldn't be
    optimizing without a real need for it. (That is, just because it's a
    little faster doesn't mean it's worth doing.)"

    But also the contrary remark by "JCM":
    "Aside from being an optimization, it's also good for documentation.
    If you see an import at the top of a file it might not be immediately
    clear how or why the module is being used. It's similar reasoning to
    why you might define variables in the narrowest scope posible."


    Thanks everybody.

    Regards


    Andreas
    Andreas Neudecker, Sep 26, 2003
    #7
  8. Andreas Neudecker

    Peter Hansen Guest

    Mel Wilson wrote:
    >
    > In article <>,
    > Peter Hansen <> wrote:
    > >I would not bother putting imports that are rarely used in only the
    > >functions which need them *unless* I had a really large module which
    > >took a long time to import and I was actually having problems with
    > >startup time for the application.

    >
    > I can see a case for
    >
    > if __name__ == '__main__':
    > import getopt
    > ...
    >
    > and even sys (for sys.argv), if the rest of the module
    > doesn't deal with sys. But that's because running as the
    > main module instead of a library module is a big change in
    > operating environment and rationale.


    Agreed!
    Peter Hansen, Oct 2, 2003
    #8
    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:
    420
    Remy Cool
    Aug 27, 2003
  2. Tobiah
    Replies:
    2
    Views:
    306
    Tobiah
    Sep 14, 2003
  3. Ben Weintraub

    Disabling modules using Modules/Setup

    Ben Weintraub, Sep 9, 2006, in forum: Python
    Replies:
    0
    Views:
    345
    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:
    291
    Peter Peyman Puk
    Mar 19, 2010
  5. ImpalerCore
    Replies:
    0
    Views:
    824
    ImpalerCore
    Mar 10, 2011
Loading...

Share This Page