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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4