[Python-Dev] Add __exports__ to modules

[Paul Prescod]

Moshe Zadka wrote:
> 
> ...
> Let me "me to" here:
> Put another way, what Greg said is just a rephrase of "don't use from
> foo import * unless foo's docos say it's OK". 

That's not the issue. It's not about keeping people out of your module.
In fact I would propose that mod.__dict__ should be as loose as ever.

It's a user interface issue. If we encourage people to learn about
modules in interactive environments like the prompt using dir(), class
browsers and IDEs then we need to create modules that are friendly for
those users. I think that the current situation is pretty bad that way.
what does CGIHTTPServer export BaseHTTPServer? And why is
CGIHTTPServer.CGIHTTPServer a class but CGIHTTPServer.BaseHTTPServer is
a module?

We go to great lengths to make the syntax newbie friendly. I think that
we should make similar efforts in a cleanly reflective class library.

> Add to that the simple
> access control of a leading underscore, and I don't see any place
> which needs it.
> 
> Something better to do would be to use
> import foo as _foo

It's pretty clear that nobody does this now and nobody is going to start
doing it in the near future. It's too invasive and it makes the code too
ugly. Why obfuscate thousands of lines of code when a simple feature can
mitigate that?

>...
> One more point against __exports__, which I hoped I would not have to
> make (but when I'm up against the timbot *and* Guido, I need to pull
> out the heavy artillery): it would *totally* stop any hope in the
> future of module level __getattr__ (or at least complicate the semantics).
> I think Alex M. is thinking of a PEP, but he's taking his time, since
> no PEPs can be considered until 2.1 is out.

__exports__ would merely be considered an implementation detail of the
"default __getattr__". Custom __getattr__'s could decide whether to
respect it or not. It doesn't complicate anything much.

 Paul Prescod