[Python-Dev] Add __exports__ to modules

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > 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).
> 
> [Marc-Andre]
> > 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.
> 
> Yes -- I came up with the same thought.

Sorry, I didn't read the whole thread on the topic. Rereading the
above paragraph I guess I should have had some more coffee at the
time of writing ;-)
 
> So here's a plan: somebody please submit a patch that does only one
> thing: from...import * looks for __all__ and if it exists, imports
> exactly those names.  No changes to dir(), or anything.

+1 -- this won't be me though (at least not this week).
 
> > 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 ;-)
> 
> In the process of looking into Zope internals I've noticed that
> proxies are indeed very useful!
> 
> I note that the IMPORT opcodes in ceval.c require that the imported
> module (as found in sys.modules[name] or returned by __import__()) is
> a real module object.  I think this is unnecessary -- at least
> IMPORT_FROM should work even if the module is a proxy or some other
> thing (I've been known to smuggle class instances into sys.modules :-)
> and IMPORT_STAR should work with a non-module at least if it has an
> __all__ attribute.

Cool.  This could make Python instances usable as "modules"
-- with full getattr() hook support !

For IMPORT_STAR I'd suggest first looking for __all__ and
then reverting to __dict__.items() in case this fails. 

BTW, is __dict__ needed by the import mechanism or would
the getattr/setattr slots suffice ? And if yes, must it
be a real Python dictionary ?
 
> > > 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.
> 
> Agreed.  Which reminds me -- would you mind reviewing Fred's new
> version of PEP 205 (weak refs)?

I'll have a look at it next week. Is that OK ?
 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

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