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.
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