> 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. 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. > 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. > > 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)? --Guido van Rossum (home page: http://www.python.org/~guido/)
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