[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/)