Should I start converting/removing uses of the types module where
There were a couple of threads on comp.lang.py with headings like "isinstance considered harmful". The conclusion was that most cases should have been coded some other way. The legitimate uses included implementing multiple dispatch (supporting calls with type differentiated signatures) , factory functions, decorator pattern (which needs to know if the object was previously decorated), and the composite pattern (which needs to know if it is dealing with an atom or a composite). Here are some of the ideas for conversion: if type(x) is int --> if x==int(x) # 3L would be passable if type(x) == types.FileType --> if hasattr(x, 'read') # StringIO would work if type(x) is str: x = x.lower() --> try: x = x.lower() except AttributeError: pass If the type check is meant to verify that an interface is supported, the try/except form maximized substitutability of objects which simulate the interface (like a UserDict or Shelve in place of a dictionary). I'm not sure this kind of conversion should be done everywhere but it could be an opportunity to remove unnecessary type dependencies. Raymond Hettinger ----- Original Message ----- From: "Neal Norwitz" <neal@metaslash.com> To: <python-dev@python.org> Sent: Friday, May 31, 2002 10:08 AM Subject: [Python-Dev] Removing types module from stdlib possible?
So where we have: assert type(lineno) is types.IntType assert type(lineno) in (types.IntType, types.LongType)
would become: assert type(lineno) is int assert type(lineno) in (int, long)
or assert isinstance(lineno, int) assert isinstance(lineno, (int, long))
Preferences?
Neal
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev