Guido> Adding __all__ just for the sake of having __all__ defined
Guido> doesn't seem to me a good use of anybody's time; since "from M
Guido> import *" already skips names starting with '_', there's no
Guido> reason to have __all__ defined in modules where it is computed to
Guido> be exactly the globals that don't start with '_'...
Sounds fine by me. I'll remove it from any modules like sre_constants that
don't import anything else.
Guido> Also, it's not immediately clear what test___all__.py tests.
hmmm... There was a reason. If I think about it long enough I may actually
remember what it was. I definitely needed it for the first few modules to
make sure I was doing things right. I eventually got into this mechanical
mode of adding __all__ lists, then adding a check_all call to the
test___all__ module. In cases where I didn't construct __all__ correctly
(say, somehow wound up with two copies of "xyz" in the list) it caught that.
Okay, so I'm back to the drawing board on this. The rationale for defining
__all__ is to prevent namespace pollution when someone executes an import
*. I guess definition of __all__ should be restricted to modules that
import other modules and don't explictly take other pains to clean up their
namespace. I suspect test___all__.py could/should be removed as well.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4