[Python-Dev] Removing types module from stdlib

[Raymond Hettinger]

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


> Should I start converting/removing uses of the types module where
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
>