Good practice when writing modules...

[r0g]

bearophileHUGS at lycos.com wrote:
> r0g:
>> a) Import all the other modules these functions depend on into the
>> modules global namespace by putting them at the top of the module or
>> should I...
>> b) Include them in each function individually.
> 
> This is a interesting topic, that requires some care.
> Generally I suggest you put them at the top, so they can be found and
> seen with less problems (*), it's the standard.
> If a function is called only once in a while (like a plotting
> function), and to import its module(s) it needs lot of time and memory
> (like matplotlib), then you may move the import inside the function
> itself, especially if such function isn't speed-critical.
> 
> 
> (*)
> I generally agree with the PEP8 but regarding this I don't follow it:
> I feel free to put more than one of them on the same line:
> import os, sys, ...
> I generally list the built-in modules first, then the well known one
> (pyparsing, numpy, etc), and then my ones or less known ones.
> 
> I also put a comment after each import, with the name of the function/
> class it is used into:
> 
> import foo # used by baz()
> import bar # used by spam()
> 
> ...
> def baz(n):
>     return foo(n) * 10
> ...
> def spam(k):
>     return bar(k) - 20
> 
> Time ago I have read an interesting article that says that comments of
> today will often become statements and declaration and tags of
> tomorrow, that is stuff that the interpreter/compiler/editor
> understands. This means that such annotations of mine may be something
> fit to become a syntax of the language. I don't have ideas on how such
> syntax can be, if you have suggestions I'm listening.
> 
> Finally in modules that contain many different things, and where each
> of them uses generally distinct modules, as a compromise I sometimes
> write code like this:
> 
> import foo # used by baz()
> 
> def baz(n):
>     return foo(n) * 10
> 
> 
> import bar # used by spam()
> 
> def spam(k):
>     return bar(k) - 20
> 
> My editor has a command that finds and lists me all the global imports
> (not indented) of the module.
> 
> Bye,
> bearophile



Thanks for the suggestions guys. I hadn't thought about putting comments
after the imports, that's a good idea, although I guess you need to be
disciplined in keeping them up to date.  All the same, given the
seemingly negligible performance hit and the nature of this particular
module I think I will probably go with includes within the functions
themselves anyway...

The module I am compiling is kind of a scrapbook of snippets for my own
development use, it has no coherent theme and I wouldn't be distributing
it or using the whole thing in a production environment anyway, just
copying the relevant functions into a new module when needed. I'm
thinking having the imports inline might make that process easier when I
do need to do it and once copied I can always move them out of the
functions declarations.

Having said that, having your editor trace these dependencies for you is
an interesting idea too. Which editor are you using? (not trying to
start an editor flame war anyone, shh!). Can this be done from idle or
are you aware of a python script that can do this maybe?

Thanks again,

Roger.