>  Well, okay. I still think we should expose these core interpreter types
>  somehow, so people can identify types easily. I don't want to be forced
>  to finding the type of sys._getframe to tell if I have a frame object on
>  my hands. Where would you put them?

Perhaps that one belongs together with sys._getframe?

You don't seem to be getting my point (or you are purposely ignoring
it), and this is frustrating for me. If these types must be exposed
they should be each be exposed in a a module (new or existing) that
defines other objects (types, functions, constants, what have you)
with a related purpose. So maybe dict views etc. can be in
collections. And maybe module, function, class, properties, some
standard decorators (classmethod, staticmethod) and various types of
methods and method wrappers can be in a module that packages code
structures. OTOH code, frame, traceback may be more suitable for a
low-level module (although I'm not sure about traceback, perhaps it is
closer exceptions). Many types of iterators may best be placed in
itertools (which defines them in the first place, many operations
there already *are* their own type). But the iterators over the
built-in collection types (list, dict etc.) should probably live in
collections again.

You see, coming up with a meaningful grouping is not all that easy --
but that's no reason to lump them all together in a "built-in-types"
module. Another criterion for grouping is whether the types make sense
for other implementations like Jython, IronPython or PyPy, or not.

I'm all for exposing these. But I'm 100% against just collecting all
those types and putting them in a single grab-bag module.