Why is there no instancemethod builtin?

[John Roth]

"John Reese" <jtr at ofb.net> wrote in message 
news:slrndb6ct5.pho.jtr at ofb.net...
> 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):

you need _both_ isinstance and the types  module to do a correct
check for any string type: isinstance(fubar, types.StringTypes).
That's because both string and unicode are subtypes of one base.

> 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

You need to do your homework better. You have, for example
NoneType and NotImplementedType in both lists.

The basic answer to your question is that the types in builtins
are there because they have uses other than type checks.
Being useful for type checks is not the criterion for being in
builtins. That's the function of the types module.

The other point to be made here is that, in most cases,
type checks are a design smell. That's not always true, but
it's the first thing to check when you see one.

John Roth