[Python-Dev] Advice in stat.py

Barry A. Warsaw barry@zope.com
Sun, 29 Jul 2001 23:21:03 -0400


>>>>> "AM" == Aahz Maruch <aahz@rahul.net> writes:

    AM> If you have a single module that imports all four of these
    AM> (and I don't think that's particularly bizarre), tracing back
    AM> any random symbol to its source becomes an annoying trek
    AM> through *five* modules.  There are probably a few other
    AM> modules I don't know about that are declared "safe" for import
    AM> *.  IMO, this quickly leads to disaster, particularly when
    AM> trying to debug someone else's code (and I've wasted more time
    AM> than I'd like over this).

    AM> It just plain goes against "explicit is better than implicit".
    AM> I think we should declare a universal policy of NEVER
    AM> recommending import *, except for interactive use.

Just because you can doesn't mean you should. :)

I think it's a good thing that those modules you mention are declared
safe for import-* but certainly in the situation you describe it isn't
a good idea to use them that way.  I don't remember a situation where
I've ever import-*'d more than a couple of modules in any single file.

There are often good reasons to use import-* at the module global
level.  Mailman has two places where this is used effectively.  The
more interesting place is in a configuration file called mm_cfg.py.
This file is where users are supposed to put all their customizations
overriding out-of-the-box defaults.  At the top of the file there's a
line like

    from Defaults import *

Which brings all the symbols from the out-of-the-box default file
(i.e. Defaults.py) into mm_cfg.py.  Overrides go after this import
line.

Mailman modules always import mm_cfg and never import Defaults, so it
makes for a very convenient way to arrange things so users only have
to care about overriding specific variables, and never have to worry
about the installation procedure overwriting their defaults ("make
install" may write a new Defaults.py but never a mm_cfg.py).

import-* is often good for creating this kind of transparent aliasing
of one module's namespace into a second.  I know <wink> no one's
talking about outlawing from-import-*.  It needs to be used
judiciously, but it definitely has its uses.

-Barry