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~
--
http://mail.python.org/mailman/listinfo/python-list
