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