On Thu, Mar 8, 2012 at 11:40 PM, Mark Shannon <mark at hotpy.org> wrote: > Other code will use whatever builtins they were given at __import__. Then they're not builtins - they're module-specific chained globals. The thing that makes the builtins special is *who else* can see them (i.e. all the other code in the process). If you replace builtins.open, you replace if for everyone (that hasn't either shadowed it or cached a reference to the original). > The key point is that every piece of code already inherits locals, globals > and builtins from somewhere else. > We can already control locals (by which parameters are passed in) and > globals via exec, eval, __import__, and runpy (any others?) > but we can't control builtins. Correct - because controlling builtins is the domain of sandboxes. > One last point is that this is a low-impact change. All code using eval, > etc. will continue to work as before. > It also may speed things up a little. Passing in a ChainMap instance as the globals when you want to include an additional namespace in the lookup chain is even lower impact. A reference implementation and concrete use cases might change my mind, but for now, I'm just seeing a horrendously complicated approach with huge implications for the runtime data model semantics for something that 3.3 already supports in a much simpler fashion. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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