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. -- http://mail.python.org/mailman/listinfo/python-list
