On Wed, Jan 10, 2001 at 07:45:44PM +0100, Thomas Wouters wrote: > On Wed, Jan 10, 2001 at 11:53:16AM -0500, Guido van Rossum wrote: > > > 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. > > Hmm.... Have you been sneaking looks at python-list again, Guido ? :-) I'm > certain the expanding of IMPORT would make a lot of people very happy. Alex > Martelli only just discovered the fact you can populate sys.modules > yourself, with non-module objects, and was wondering about its legality and > compatibility. > > I, for one, am very +1 on the idea, also on MAL's idea to do our best in the > IMPORT_STAR case (try dict.items(), etc.) +1 ... I'm always up for removing type restrictions. Did that with the bytecodes in function objects a while back. Cheers, -g -- Greg Stein, http://www.lyra.org/
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