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