two conflicting meanings of builtins in python 3 (python 3.1, python 3k, python3000)

I just posted below query to comp.lang.python, but i feel this kind of question has some kind of right-of-way here on Stack Overflow, too, so be it repeated. the essence: why does ‘builtins’ have two distinct interpretations in Python 3?

I would be very gladly accept any commentaries about what this sentence, gleaned from http://celabs.com/python-3.1/reference/executionmodel.html, is meant to mean, or why gods have decided this is the way to go. i anticipate this guy named Kay Schluehr will have a say on that, or maybe ev开发者_如何学编程en the BDFL will care to pronounce __builtins__ the correct way to his fallovers, followers, and fellownerds::

  The built-in namespace associated with the execution of
  a code block is actually found by looking up the name
  __builtins__ in its global namespace; this should be a
  dictionary or a module (in the latter case the module’s
  dictionary is used). By default, when in the __main__
  module, __builtins__ is the built-in module builtins;
  when in any other module, __builtins__ is an alias for
  the dictionary of the builtins module itself.
  __builtins__ can be set to a user-created dictionary to
  create a weak form of restricted execution.

it used to be the case that there were at least two distinct terms, ‘builtin’ (in the singular) and ‘builtins’ (in the plural), some of which existed both in module and in dict form (?just guessing?). now there is only builtins, so fortunately the ambivalence between singular and plural has gone—good riddance.

but why does __builtins__ change its meaning depending on whether this is the scope of the ‘script’ (i.e. the module whose name was present, when calling python foobar.py) or whether this is the scope of a secondary module (imported or executed, directly or indirectly, by foobar.py)? i cannot understand the reasoning behind this and find it highly confusing.

rationale: why do i care?—i want to be able to ‘export names to the global namespace that were not marked private (by an underscore prefix) in a python module that i execute via exec( compile( get ( locator ), locator, 'exec' ), R ) where R is supposed to going to hold the private names of said module’. it is a little arcane but the basic exercise is to by-pass python’s import system and get similr results... it is all about injecting names into the all-global and the module-global namespaces.

---

getattr(__builtins__, '__dict__', __builtins__) should give you the dict that you want to update to "export names to the global namespace", whether __builtins__ is a dict (then it doesn't have a __dict__ attribute so getattr returns the third argument, which is the dict __builtins__ itself) or a module (then it does have that attribute and getattr returns it). This is the workaround. As to why Python's documented to work in a way requiring such a tangled workaround, I'd classify it as an unfortunate case of an implementation issue surfacing to user-visible (and indeed documented) level (sigh). Pity we didn't think of fixing it in the move to Python 3, but it's too late to make backwards-incompatible changes now:-(.