[Baypiggies] Baypiggies snippets

Chad Netzer chad.netzer at gmail.com
Tue Mar 27 19:56:39 CEST 2007

On 3/27/07, Keith Dart <keith at dartworks.biz> wrote:
> Also, I thought "... import *" was "frowned upon".

Well, it can't be anywhere nearly as frowned upon as altering the
builtin namespace. :)

Here is a little bit of my perspective on "from some_module import *".
 Basically, one has to be wary of it since as things are added to a
module over time, obviously there is more potential for hidden
namespace clashes.  Someone could add a function with the same name as
your own helper function in a different module, and depending on the
order of "from import *" statements, you would now be using the wrong
function (all without ever changing your code, just upgrading some
other module).

So, that is one obvious reason to prefer only explicitly importing the
things you need.  However, even if you take that risk in your own
module, and only intend to use the imported functions within that
module, you now have to take care not to re-export them.

If your module is bar.py, and you import everything from foo.py, ie.:

% cat bar.py
from foo import *

And now someone else using bar does:

from bar import *

Unless you took steps to cleanse the namespace, they will get
everything from both foo and bar.  That is a very compelling reason to
use the __all__ list in a module, to explicitly declare the exported


Finally, in Python it is easy to give things short names.  When I use
the Numeric module (now being superceded by numpy), I get tired of
typing "Numeric" all the time.  So, I rename it as "Num", or "N".


import Numeric as Num


N = Numeric

if I need to use a specific function a lot, I just grab it:

from Numeric import pi


pi = Numeric.pi

So, if you use "from module import *" in your framework, be aware of
the consequences, and clean up after yourself with __all__.  If you
need to reduce typing, see if you can get by with a temporary short

Hope that helps a bit.


More information about the Baypiggies mailing list