__all__

[Ethan Furman]

Paul Woolcock wrote:
> The gurus will have to correct me if this is not an accepted practice, 
> but I know some projects (Fabric is the one that comes to mind) will 
> define a submodule specifically for the 'from blah import *' situation. 
> The submodule would be called "api", or something like that, so you can 
> do: 'from mymodule.api import *' to separate the items you want to 
> include in your public api, while still keeping other names importable 
> by 'import blah'

Have I said lately how much I *love* Python?  Programming is fun again!

Thanks, Paul, that was the clue I needed.  Had to do some thinking since 
dbf is back to a single module, and no longer a package... here's what I 
came up with:

-------------------------------------------------------------
class fake_module(object):
     def __init__(self, name, *args):
         self.name = name
         self.__all__ = []
         for func in args:
             name = func.__name__
             self.__dict__[name] = func
             self.__all__.append(name)
     def register(self):
         sys.modules["%s.%s" % (__name__, self.name)] = self
-------------------------------------------------------------

then in my module (towards the bottom since I have to have all my 
functions/classes written that I want to include) I can have

fake_module('api', class1, class2, func1, exception1).register()

Now somebody else who wants to include the classes, exceptions, etc, 
that make up the primary part of the dbf module can do

from dbf.api import *

but

help(dbf)

will continue to list all the other public utility stuff (defined in 
dbf.__all__) normally.

Thanks to all!

~Ethan~