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