On Fri, Feb 21, 2014 at 8:50 PM, Steven D'Aprano <st...@pearwood.info> wrote: > The history of __builtins__ with an S is quite old. It's used for > performance reasons, and originally it was supposed to be used for > sandboxing Python, but that turned out to not work. So although it still > exists even in Python 3, it's a performance hack for the CPython > interpreter, and does not exist in Jython, IronPython or other > interpreters.
I can see how it's a small memory optimization to store __builtins__ in globals. Otherwise a function would need another slot for func_builtins, just as a frame has f_globals and f_builtins. That's assuming CPython retains the ability to use a custom builtins namespace. As you say, that isn't even possible in other Python implementations such as Jython. As to this being a "performance hack", I can't see how using __builtins__ improves performance, since the interpreter keeps a reference to the dict of the __builtin__ module. The attempt at sandboxing runs deeper than just customizing __builtins__. Search the CPython 2.x source for PyEval_GetRestricted. The latter returns true when a frame's f_builtins isn't the interpreter's builtins. Restricted code can't directly create file objects, unmarshal code objects (from .pyc), set old-style class attributes, or read/write restricted members of built-in objects such as a function's __doc__, among other restrictions. But trying to lock Python down in an otherwise uncontrolled environment is harder than playing Whac-A-Mole. Almost all of the restricted API was removed from Python 3, except for a few legacy flags. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
