[Tutor] Regarding Exceptions

[eryksun]

On Fri, Feb 21, 2014 at 8:50 PM, Steven D'Aprano <steve at 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.