[Python-Dev] Add __exports__ to modules

[M.-A. Lemburg]

Guido van Rossum 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).

Can't we use the existing attribute __all__ (this is currently
only used for packages) for this kind of thing. As other have already
remarked: I would rather like to see this attribute being used
as basis for 'from M import *' rather than enforce the access
restrictions like the patch suggests.

Access control mechanisms should be treated in different ways
such as wrapping objects using access-control proxies (see mx.Proxy
for an example of such an implementation) and on-demand only.
I wouldn't wan't to pay the performance hit for each and every
lookup in all my Python applications just because someone out
there feels that "from M import *" has a meaning in life
apart from being useful in interactive sessions to ease typing ;-)
 
> I like it.  This has been asked for many times.  Does anybody see a
> reason why this should *not* be added?
> 
> Tim remarked that introducing this will prompt demands for a similar
> feature on classes and instances, where it will be hard to implement
> without causing a bit of a slowdown.  It causes a slight slowdown (an
> extra dictionary lookup for each use of "M.v") even when it is not
> used, but for accessing module variables that's acceptable.  I'm not
> so sure about instance variable references.

Again, I'd rather see these implemented using different
techniques which are under programmer control and made
explicit and visible in the program flow. Proxies are ideal
for these things, since they allow great flexibility while
still providing reasonable security at Python level.

I have been using the proxy approach for years now and 
so far with great success. What's even better is that
weak references and garbage finalization aids come along with
it for free.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/