«

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 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

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 <> 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" <> 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

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

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

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!