"John Reese" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 -- http://mail.python.org/mailman/listinfo/python-list
