[Python-Dev] the nature of the symbols in types

[Skip Montanaro]

There seem to be two classes of symbols in the types module, those with a
one-to-one mapping to objects in builtins (IntType, StringType, etc) and
those you have to work a bit more diligently to get at from Python code
(TracebackType, UnboundMethodType, etc).  It's clear the uses of the common
types can be replaced, perhaps pretty mechanically.  They also probably
account for 99.5% of all uses of the module.  Furthermore, I would hazard a
guess that the tougher-to-get-at types are probably used predominantly in
introspective (and thus specialized) code.  A quick scan through the Python
source bears this out:

    Bastion.py, bdb.py, calendar.py, copy.py, copy_reg.py, dis.py,
    imputil.py, inspect.py, pickle.py, posixfile.py, pydoc.py, traceback.py,
    unittest.py, warnings.py, distutils/dist.py, distutils/unixccompiler.py,
    cgitb.py, xmlrpclib.py

The above files contain references to one or more of the following names:

    BufferType, BuiltinFunctionType, BuiltinMethodType, ClassType, CodeType,
    DictProxyType, EllipsisType, FrameType, FunctionType, GeneratorType,
    InstanceType, LambdaType, MethodType, ModuleType, NoneType, SliceType,
    TracebackType, UnboundMethodType, XRangeType

I suspect most of these uses could be replaced fairly easily by the authors
of code that uses them, though it wouldn't be quite as automatic as for the
common symbols.  Some could probably just be deleted.  anything that can
just be gotten by calling type() might be a candidate.  For some, it should
be fairly straightforward to add appropriate symbols to builtins.  'buffer',
'slice' and 'xrange' could be replaced by a callable type.  Others could be
just non-callable objects that expose the various type objects.  Adding the
obvious symbol for 'class' to builtins obviously wouldn't work.

Skip