> > > 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/L2OC46WRQ7QRKT5S4VND5ITFBUMSS6SN/ Code of Conduct: http://python.org/psf/codeofconduct/
