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 builtins. The f_builtins field points to the dictionary of this frame's builtin namespace. Normally the builtins namespace is the same as the __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 eval() or exec and specify a 'globals' dictionary with a __builtins__ member. If present, this becomes the builtins for the code, shows up in f_builtins 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 only None, but this is probably considered implementation dependent.