On Thu, Mar 8, 2012 at 11:40 PM, Mark Shannon <m...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com