[James Y Knight]
Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where. Option #2 seemed to be rejected last time, and option #1 was given approval, so that's what I wrote a patch for. It sounds like it's getting pretty strong "no" votes this time around, however. Therefore, I would like to suggest option #3, with <newmodule> being, say, 'internals'.
[GvR]
+1
That gives them a place to live and doesn't clutter __builtin__. However, it should be named __internals__. The next question is how to document it. My preference is to be clear that it is implementation specific (Jython won't have cell, PyCFunction, and dictproxy types); that it is subject to change between versions (so as not to prematurely immortalize design/implementation accidents); and that they have only esoteric application (99.9% of programs won't need them and should avoid them like the plague). Calling it __internals__ will help emphasize that we are exposing parts of the implementation that were consciously left semi-private or undocumented. Raymond