[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre_constants.py (etc)

Guido van Rossum guido@digicool.com
Thu, 15 Feb 2001 18:45:54 -0500


>     Fredrik> can anyone explain why it's a good idea to have totally
>     Fredrik> incomprehensible stuff like
> 
>     Fredrik>     __all__ = locals().keys()
>     Fredrik>     for _i in range(len(__all__)-1,-1,-1):
>     Fredrik>         if __all__[_i][0] == "_":
>     Fredrik>             del __all__[_i]
>     Fredrik>     del _i
> 
>     Fredrik> in my code?
> 
> Please don't shoot the messenger... ;-)

I'm not sure you qualify as the messenger, Skip.  You seem to be
taking this __all__ thing way beyond where I thought it needed to go.

> In modules that looked to me to contain nothing by constants, I used the
> above technique to simply load all the modules symbols into __all__, then
> delete any that began with an underscore.  If there is no reason to have an
> __all__ list for such modules, feel free to remove the code, just remember
> to also delete the check_all() call in Lib/test/test___all__.py.

Rhetorical question: why do we have __all__?

In my mind we have it so that "from M import *" doesn't import
spurious stuff that happens to be a global in M but isn't really
intended for export from M.  Typical example: Tkinter is commonly used
in "from Tkinter import *" mode, but accidentally exports a few
standard modules like sys.

Adding __all__ just for the sake of having __all__ defined doesn't
seem to me a good use of anybody's time; since "from M import *"
already skips names starting with '_', there's no reason to have
__all__ defined in modules where it is computed to be exactly the
globals that don't start with '_'...

Also, it's not immediately clear what test___all__.py tests.  It seems
that it just checks that the __all__ attribute exists and then that
"from M import *" imports exactly the names in __all__.  Since that's
how it's implemented, what does this really test?  I guess it tests
that the import mechanism doesn't screw up.  It could screw up if it
was replaced by a custom import hack that hasn't been taught to look
for __all__ yet, for example, and it's useful if this is caught.  But
why do we need to import every module under the sun that happens to
define __all__ to check that?

--Guido van Rossum (home page: http://www.python.org/~guido/)