[Python-Dev] Add __exports__ to modules

[Skip Montanaro]

    > On Fri, 05 Jan 2001 15:14:41 -0500, Guido van Rossum <guido@python.org> wrote:
    > Please have a look at this SF patch:
    > 
    > http://sourceforge.net/patch/?func=detailpatch&patch_id=102808&group_id=5470
    > 
    > This implements control over which names defined in a module are
    > externally visible: if there's a variable __exports__ in the module,
    > it is a list of identifiers, and any access from outside the module to
    > names not in the list is disallowed.  This affects access using the
    > getattr and setattr protocols (which raise AttributeError for
    > disallowed names), as well as "from M import v" (which raises
    > ImportError).

I have to agree with Moshe.  If __exports__ is implemented for modules we'll
have multiple, different access control mechanisms for different things,
some of which thoughtful programmers would be able to get around, some of
which they wouldn't.  Here are the ways I'm aware of to control attribute
visibility (there may be others - I don't usually delve too deeply into this
stuff):

  * preface module globals with "_": This just prevents those globals from
    being added to the current namespace when a programmer executes "from
    module import *".  Programmers can workaround this by attribute access
    through the module object or by explicitly importing it: "from module
    import _foo" works, yes?

  * preface class or instance attributes with "__":  This just mangles the
    name by prefacing the visible name with _<classname>.  The programmer
    can still access it by knowing the simple name mangling rule.

In both cases the programmer can still get at the attribute value when
necessary.

If you were to add some sort of access control to module globals, I would
have thought it would have been along the same lines as the existing
mechanisms in place to "hide" class/instance attributes.  Would it be
possible (or desirable) to add the name mangling restriction to module
globals as an alternative to this more restrictive implementation?  What
about the chances that class/instance attribute hiding will get more
restrictive in the future?  Finally, are the motivations for wanting to
restrict access to module globals and class/instance attributes that much
different from one another that they call for fundamentally different
mechanisms?

Skip