Exploring the frame object
As I noted in passing, Python frame objects also
have a vaguely mysterious
f_builtins member. On one level, frame
objects have this member because they are more or less representations
of the CPython (code) frame structure, and the C-level code frame
structure has an
f_builtins field. So, what is this field?
(Quite a lot of the Python internal objects work this way; they have the members that they do mostly because they're Python representations of C structures).
We can say that Python searches for names in three namespaces, those
being the function locals, the (module) globals, and finally the
f_builtins field points to the dictionary of this
frame's builtin namespace. Normally the builtins namespace is the same
__builtins__ module's namespace, but it doesn't have to be;
you can manipulate it under certain circumstances.
(It is technically inaccurate to say that CPython searchs for names in three namespaces, because CPython actually knows in advance whether a particular name is a function local variable or not.)
The directly accessible ways are to use
exec and specify
a 'globals' dictionary with a
__builtins__ member. If present,
this becomes the builtins for the code, shows up in
in frames, and so on. Any code frame with a non-standard value for
f_builtins is a 'restricted' frame, and various bits of the CPython
innards behave differently (usually they forbid various operations,
for example setting attributes on classes). In turn all of this
seems to be present to support the now-deprecated rexec.py module, which attempts to (you
guessed it) restrict what some untrusted Python code can do.
Under extremely odd situations (I think you'd need to write a CPython
module in C), you can create a frame with a globals dictionary that does
not have a
__builtins__ member. If this happens, CPython makes up a
very small builtins namespace for the new frame; currently it contains
None, but this is probably considered implementation dependent.