Greg Ewing wrote: > Zooko <zooko@zooko.com>: > > >>Now what I would *like* is that instead of doing "import os" to load code, >>instead the caller provides, or doesn't provide the os module as part of the >>construction/invocation of A. >> >>I don't have a clear idea yet of how that could be implemented in a >>Pythonic, compatible way. > > > Maybe, instead of there being one ultra-global namespace for importing > modules from, it should be part of a function's environment. By > default a function invocation would inherit the "import environment" > of it's caller, but the caller could override this to provide a more > restricted environment. Inheriting things is not the capability way. Passing capabilities that allow imports is, of course, but isn't very Pythonic. I'm not sure there's a neat way to fix this that keeps both camps happy. > This would be equivalent to passing in a set of allowable > modules as an implicit parameter to every call. Making it explicit would make me happy. Can you pass parameters to an import? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
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