Is 'isinstance()' the right thing?

[Kragen Sitaker]

juenglin at informatik.uni-freiburg.de (Ralf Juengling) writes:
> Why aren't types not the right machinery for specifying the support 
> of a protocol? Whenever someone introduces a new protocol, he would 
> set up a new abstract type (or class), say (to become more Python related 
> at the end)
> 
> class _iterator_:
>     """This is an abstract class defining the iterator protocol
>     """
>     def __iter__(self): raise NotImplementedError
>     def next(self): raise NotImplementedError
> 
> for the iterator protocol. Any class implementing the iterator 
> protocol would be a subclass of '_iterator_' (probably among others) 
> to signal, it is implementing this protocol.

The problem is that once you provide a mechanism for requiring
arguments to be derived from a particular type, people will start
requiring them to be derived from lots of different types, and some of
those types won't be interface types.

The result, in languages that support this, like C++ and Java, is
tight coupling between classes: class A requires that arguments to its
bletch() method be derived from class B, which typically means they
have to inherit class B's bugs and stupid design mistakes, and also
means that they have to be written by somebody who knew about class B.

In one Python application I currently work on, we've been able to
switch between using lists and Numeric arrays in several places with
very little difficulty.