RFC: reimplementing the Type type as an extension type.

[Tom]

I'm thinking about reimplementing the type type as an extension type.  The
purpose would be to make much additional information about a type available
from the type object.  This info would include the following:

 Attributes (all read-only):
__name__ - same as for the built-in type objects.
__members__ - a tuple containing the names of the special attributes
supported by all objects of the type.
__methods__ - a tuple containing the names of the methods supported by all
objects of the type.
    These are the same as the 'generic' special attributes currently
available on objects of some types, but implemented on the type object, not
the object itself.  Currently, some are implemented using the method table,
some are hard-coded (for types that don't have a method table, I suppose),
and many aren't implemented at all (why?).  Should I include info about the
object type of each attribute as well?  whether the attribute is read-only?
What about pre-defined dictionary attributes (eg. __doc__, __file__,
__path__, but these aren't guaranteed to exist).
__type__ - the object of the built-in type type corresonding to this
extended type.
__basicsize__ - in bytes, corresponds to basic size field in the types
definition structure.
__itemsize__ - in bytes, corresponds to item size field in the types
definition structure.

 Methods:
new(args) - create and return a new object of the type (like the new
module).
false() - create and return an object of the type.  This would return a
'sample' object - see types.py for sample objects of each type.  These
objects correspond to false in truth testing (for relevant types) and are
essentially null objects.
hasdict() - return true if the type has a namespace dictionary that can be
accessed through the dot operator (so, only true for ModuleType,
InstanceType, and ClassType).
numeric()
sequence()
map() - returns true if the type implements the corresponding (numeric,
sequence, and map) methods.
range() - returns the min and max value of the type (if relevant) in an XRan
ge object (with step = None).

 Attributes (but probably implemented as Methods since Python doesn't have
enums):
mutability - IsMutable()
composition - IsAtomic(),IsCompound() - both can return false if type has no
value (just special attributes).
copyable - CanCopy() - eg. how does the copy.py module handle this type.
(In honour of the recent 'how can you clone a string thread in c.p.l.)
externality - HasExternal() - refers to external resources (must be
destroyed to release the resource).
callable - IsCallable()

 A few other features/comments:
- I would also supply a function similar to the built-in type() function
(but it would return one of these 'extended' type objects).
- There would be a mechanism for registering information about other
extension types.
- I would provide seperate type objects for those that don't have them in
the built-in type system.  Currently:
  LambdaType == FunctionType
  UnboundMethodType == MethodType
  BuiltinMethodType == BuiltinFunctionType
 Given that their type fields aren't distinguishable, how do I deteremine
which is which?  Does anybody care about this distinction?  Maybe they are
the same for a good reason?

I am writing this post to ask for suggestions or requests, including
corrections to my terminology, and suggestions for member names.  But most
of all please tell me if someone has already done this, or if there are any
significant changes pending to the source code that I should know about, or
if this is just a bad idea for some reason.

Tom.