Where to place imports

Discussion in 'Python' started by John [H2O], Jan 23, 2009.

  1. John [H2O]

    John [H2O] Guest

    Hello, Im writing some modules and I am a little confused about where to
    place my imports...

    I don't really do any class programming yet, just defining a bunch of
    functions, so presently I have something along the lines of:

    import sys
    import os
    import traceback


    def Foo1(a,b):
    import numpy
    import datetime
    return c

    def Foo2(a,b):
    import datetime

    c = Foo1(a,b)
    return c

    etc...

    Above obviously just for the form, but the point is, in some cases I may
    import modules twice, but other times I may not use them at all, so should I
    import everything into the main module? Or individually import them into
    functions. Is there a performance penalty either way?

    Pointers to a good reference are appreciated...


    --
    View this message in context: http://www.nabble.com/Where-to-place-imports-tp21627895p21627895.html
    Sent from the Python - python-list mailing list archive at Nabble.com.
     
    John [H2O], Jan 23, 2009
    #1
    1. Advertising

  2. John [H2O] schrieb:
    > Hello, Im writing some modules and I am a little confused about where to
    > place my imports...
    >
    > I don't really do any class programming yet, just defining a bunch of
    > functions, so presently I have something along the lines of:
    >
    > import sys
    > import os
    > import traceback
    >
    >
    > def Foo1(a,b):
    > import numpy
    > import datetime
    > return c
    >
    > def Foo2(a,b):
    > import datetime
    >
    > c = Foo1(a,b)
    > return c
    >
    > etc...
    >
    > Above obviously just for the form, but the point is, in some cases I may
    > import modules twice, but other times I may not use them at all, so should I
    > import everything into the main module? Or individually import them into
    > functions. Is there a performance penalty either way?


    Usually, you should import on the top of the module. That's the cleanest
    way, and the most performant one.

    There is a small performance penalty when doing it inside functions -
    but not too much. It boils down to a lookup if the imported module has
    already been imported before.


    The only valid reason for doing imports inside functions is if you
    otherwise get into circular dependency hell, or have modules that need
    some manipulation of the sys.path before they actually can be imported.
    This is never true for system modules, and certainly to avoid if possible.

    Diez
     
    Diez B. Roggisch, Jan 23, 2009
    #2
    1. Advertising

  3. John [H2O]

    John [H2O] Guest

    So it isn't inefficient to import a bunch of modules that may not be used,
    say if only one function is used that doesn't rely on a larger module like
    numpy or pylab?

    Thanks.


    Diez B. Roggisch-2 wrote:
    >
    > John [H2O] schrieb:
    >> Hello, Im writing some modules and I am a little confused about where to
    >> place my imports...
    >>
    >> I don't really do any class programming yet, just defining a bunch of
    >> functions, so presently I have something along the lines of:
    >>
    >> import sys
    >> import os
    >> import traceback
    >>
    >>
    >> def Foo1(a,b):
    >> import numpy
    >> import datetime
    >> return c
    >>
    >> def Foo2(a,b):
    >> import datetime
    >>
    >> c = Foo1(a,b)
    >> return c
    >>
    >> etc...
    >>
    >> Above obviously just for the form, but the point is, in some cases I may
    >> import modules twice, but other times I may not use them at all, so
    >> should I
    >> import everything into the main module? Or individually import them into
    >> functions. Is there a performance penalty either way?

    >
    > Usually, you should import on the top of the module. That's the cleanest
    > way, and the most performant one.
    >
    > There is a small performance penalty when doing it inside functions -
    > but not too much. It boils down to a lookup if the imported module has
    > already been imported before.
    >
    >
    > The only valid reason for doing imports inside functions is if you
    > otherwise get into circular dependency hell, or have modules that need
    > some manipulation of the sys.path before they actually can be imported.
    > This is never true for system modules, and certainly to avoid if possible.
    >
    > Diez
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
    >


    --
    View this message in context: http://www.nabble.com/Where-to-place-imports-tp21627895p21628590.html
    Sent from the Python - python-list mailing list archive at Nabble.com.
     
    John [H2O], Jan 23, 2009
    #3
  4. John [H2O] schrieb:
    > So it isn't inefficient to import a bunch of modules that may not be used,
    > say if only one function is used that doesn't rely on a larger module like
    > numpy or pylab?


    Well, importing can take bit of time - but that's a short latency at
    startup-time, if anything.

    And if your module gets imported inside a function, it *is* used, isn't it?

    Diez
     
    Diez B. Roggisch, Jan 23, 2009
    #4
  5. John [H2O]

    Steve Holden Guest

    Diez B. Roggisch wrote:
    [...]
    > The only valid reason for doing imports inside functions is if you
    > otherwise get into circular dependency hell, or have modules that need
    > some manipulation of the sys.path before they actually can be imported.
    > This is never true for system modules, and certainly to avoid if possible.
    >

    Well there is also the somewhat obscure point that an import of specific
    names inside a function makes them local, which *might* make a
    performance difference with tight loop nesting inside - though obviously
    the need for such will best be determined by benchmarking:

    >>> def f1():

    .... from os.path import join
    .... print join
    ....
    >>> from os.path import join
    >>> def f2():

    .... print join
    ....
    >>> dis.dis(f1)

    2 0 LOAD_CONST 1 (-1)
    3 LOAD_CONST 2 (('join',))
    6 IMPORT_NAME 0 (os.path)
    9 IMPORT_FROM 1 (join)
    12 STORE_FAST 0 (join)
    15 POP_TOP

    3 16 LOAD_FAST 0 (join)
    19 PRINT_ITEM
    20 PRINT_NEWLINE
    21 LOAD_CONST 0 (None)
    24 RETURN_VALUE
    >>> dis.dis(f2)

    2 0 LOAD_GLOBAL 0 (join)
    3 PRINT_ITEM
    4 PRINT_NEWLINE
    5 LOAD_CONST 0 (None)
    8 RETURN_VALUE
    >>>


    Not a major issue, just another aspect of the question ... and of course
    the OP should take the advice already given unless and until performance
    becomes a problem (since it usually won't).

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
     
    Steve Holden, Jan 23, 2009
    #5
  6. Steve Holden schrieb:
    > Diez B. Roggisch wrote:
    > [...]
    >> The only valid reason for doing imports inside functions is if you
    >> otherwise get into circular dependency hell, or have modules that need
    >> some manipulation of the sys.path before they actually can be imported.
    >> This is never true for system modules, and certainly to avoid if possible.
    >>

    > Well there is also the somewhat obscure point that an import of specific
    > names inside a function makes them local, which *might* make a
    > performance difference with tight loop nesting inside - though obviously
    > the need for such will best be determined by benchmarking:


    But that could be mitigated using aliasing, which is a more general
    optimization technique, as it works not only for imported names but also
    for e.g. bound methods, or any other chained lookups.

    Diez
     
    Diez B. Roggisch, Jan 23, 2009
    #6
  7. On Fri, 23 Jan 2009 17:48:19 +0100, Diez B. Roggisch wrote:

    > The only valid reason for doing imports inside functions is if you
    > otherwise get into circular dependency hell, or have modules that need
    > some manipulation of the sys.path before they actually can be imported.


    Or if you want to make it clear that only a single function uses the
    imported module, or if you wish to avoid a potentially expensive import
    until the last possible moment when you actually need it, or if you're
    finicky about namespace pollution, or if you just like to put your
    imports inside functions because you're weird and never use threads.

    All of these are valid reasons. Whether they will give you the love and
    respect of your fellow Python programmers is another question.


    --
    Steven
     
    Steven D'Aprano, Jan 23, 2009
    #7
    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. Edward
    Replies:
    1
    Views:
    2,486
    Edward
    Jul 8, 2003
  2. Bite My Bubbles

    REFERENCE VS IMPORTS

    Bite My Bubbles, Aug 25, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    362
    Bite My Bubbles
    Aug 25, 2003
  3. Albert
    Replies:
    4
    Views:
    11,041
    Albert
    Jul 10, 2008
  4. zildjohn01
    Replies:
    0
    Views:
    694
    zildjohn01
    Feb 22, 2011
  5. Victor Hooi
    Replies:
    1
    Views:
    130
    Devin Jeanpierre
    Nov 25, 2013
Loading...

Share This Page