Why is there no instancemethod builtin?

[John Reese]

Why hello there ha ha.

I have got in the habit of testing the types of variables with
isinstance and the builtin type names instead of using the types
module, as was the style back around Python 2.1.  That is, rather than

  if type(x) == types.ListType:

I now do:
 
  if isinstance(x, list):
 
It is my understanding that this is what people do nowadays.  One
problem I have, though, is that not all type names are available as
builtins.  Just looking through the types declared in types, the
following are builtins:

  bool, buffer, complex, dict, file, float, list, long, 
  object, slice, str, tuple, type, unicode, xrange, NoneType,
  NotImplementedType

And the following are not:

  dictproxy, ellipsis, frame, function, instancemethod, module,
  traceback, instancemethod, NoneType, NotImplementedType

So for any in the latter batch, I have to import types after all.  I
assume the dividing line is whether the name is useful as a
constructor.  Still, I feel there's some inconsistencies in the
usefulness of the new type system.  Why do str and unicode derive from
basestring, while list and tuple are independent types?  list and
tuple support most of the same operations... it seems like either they
should also have an abstract base class or str and unicode shouldn't,
because duck typing doesn't really require that.

It also seems like types may be on the way out, because I don't see
constants for set or frozenset.

I'm not sure I have a question here, just pointing out what I see as
some flaws in the new type system.