[Python-Dev] creating __all__ in extension modules
Guido van Rossum
guido@digicool.com
Mon, 05 Feb 2001 00:04:56 -0500
> Fred> I don't think adding __all__ to C modules makes sense. If you
> Fred> want the equivalent for a module that doesn't have an __all__, you
> Fred> can compute it easily enough. Adding it when it isn't useful is a
> Fred> maintenance problem that can be avoided easily enough.
>
> I thought I answered this question already when Fredrik asked it. In os.py,
> to build its __all__ list based upon the myriad different sets of symbols it
> might have after it's fancy footwork importing from various os-dependent
> modules, I think it's easiest to rely on those modules telling os what it
> should export.
So use dir(), or dir(posix), to find out what you've got.
I'm strongly -1 to adding __all__ to extensions. Typically, *all*
symbols exported by an extension are to be imported. We should never
rely on __all__ existing -- we should just test for its existence and
have a fallback, just like from...import * does.
--Guido van Rossum (home page: http://www.python.org/~guido/)