I'm not sure that I would let `export` use the existing `__all__` machinery anyway. Maybe in a module that uses `export` there should be a different rule that disallows importing anything from it that isn't explicitly exported, regardless of what form of import is used (`__all__` *only* affects `import *`).
+1 here.
As you point out, __all__ is only really required (or does anything) for "import *" -- and frankly, import * is rarely the right thing to do anyway. So I virtually never use import *, and never write an __all__.
But having a way to specify exactly what names are importable at all could make for a cleaner and more explicit API for a module.
I am curious how hard that would be to implement though. A module as a namespace (global) -- that namespace is used in the module itself, and is exactly what gets imported, yes? So would a whole etra layer of some sort be required to support this feature?
Also, if you did:
import the_module
would all the names be available in the modules namespace? but some couldn't be imported specifically? That is:
import the_module
the_module.sys
would work, but
from the_module import sys
would not work?
That might be odd and confusing.
-CHB
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython