protocols, inheritance and polymorphism

Donn Cave donn at u.washington.edu
Tue Nov 23 20:10:02 EST 2004


In article <mqedndyH_YCYUT7cRVn-uQ at rogers.com>,
 "Dan Perl" <danperl at rogers.com> wrote:
...
> I was rather saying that subtype polymorphism (through inheritance, rather 
> than protocols) and checking with isinstance is safer.  You are right that 
> inheritance is not foolproof either.  But if someone is inheriting from your 
> base class, they are bound to be more aware of the interface and to be more 
> careful when overriding an attribute that would completely change the 
> behavior of their objects.  A protocol can be broken in many other ways.  In 
> the case of a well known protocol like iterators most people know better 
> than to use the name "next" for any attribute other than a method used for 
> iteration.  But if you create a little known protocol interface with a 
> poorly chosen attribute name like "x" it is very likely that someone is 
> going to use the same name in a class for some attribute that is completely 
> different (e.g., data instead of a method).  And if they are not explicitly 
> inheriting from a base class they may never be aware they are obfuscating a 
> behavior that is being used somewhere in their code.  Note that I said 
> "explicitly inheriting", which infers that people can make the same kind of 
> mistakes also if they inherit from some class without knowing it.
> 
> This discussion feels to me like deja vu.  It's a kind of philosophical 
> discussion in which I've been involved before, with me on this side of the 
> argument and with other people being on the side that says that "python is 
> designed for people who rely more on their users and for users who are more 
> reliable, the other people should use other languages" (my own 
> paraphrasing).  I'm not saying this with any disrespect toward the other 
> side.  After all, this is probably inherent in a dynamically typed language, 
> and dynamic typing has other advantages instead.  It's just something I 
> still have to get used to: what is python good for, in what kind of 
> applications it should be used and when should you just use a different 
> (perhaps a strongly typed) language.

I'm very sympathetic to the advantages of static typing
(NB, I read here that Python is strongly, though dynamically,
typed.  It is not statically typed.)  Rather than embrace
subtype polymorphism through inheritance, however, I see it
as evidence that no one has figured out how to make static
typing really work with OOP.  There has to be a better way
to do it.

   Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list