Is there a consensus on how to check a polymorphic instance?

[Mike Meng]

hi all,
I'm a newbie Python programmer with a C++ brain inside. I have a
lightweight framework in which I design a base class and expect user to
extend. In other part of the framework, I heavily use the instance of
this base class (or its children class). How can I ensure the instance
IS-A base class instance, since Python is a fully dynamic typing
language?

I searched and found several different ways to do this:

1. In `Text Processing in Python', David Mertz suggests using `hasattr'
to check abilities instead of type checking.

2. In ActiveState's Python Cookbook site, Alex Martelli suggested a
safe and accurate `look before you leap' technique on
http://aspn.activestate.com/ASPN/Coo...n/Recipe/52291

3. In this group, some others suggest using isinstance() builtin
function to check instance.

Now my questions:
1. Is my design speaks native Pythonish? Such design is native in C++
and Java OO style, but I'm not sure about this in Python.

2. As I state in title, is there a consensus on how to check a
polymorphic instance? I find all the three ways above is a little bit
tedious compared with C++ and Java, in which compile-time type checking
ensures the interface protocol, any better ideas in Python?
Any comments will be appreciated.

[Mike Meng]

> I come from a very conservative background in software development

and strong checks are deeply rooted in my mind.

So do I, Dan.

I just can't imagine a `wild' object whose interface is valid can
truely do the right things. While in fact, when I typing this word, I
realize we can't ensure the internal protocol will be obeyed even when
the object IS-A base class instance.

Maybe it's time to rethink.

It seems to me the virtue of dynamic langauge is, if it looks like a
cat, it's a cat. But the problem is still there: how do you know what
it looks like before you treat it as a cat? isinstance(), , as Steve
state, is too rigid.

[Donn Cave]

Quoth "Dan Perl" <da*****@rogers .com>:
| "Donn Cave" <do**@u.washing ton.edu> wrote in message
| news:do******** *************** *@gnus01.u.wash ington.edu...
| > 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.
|
| You're right, I should have said statically typed instead of strongly typed.
|
| But did you really mean "no one has figured out how to make *static* typing
| really work with OOP" or did you mean *dynamic* typing?

Static. I figure dynamic & OOP get along fine -- as Smalltalk showed,
along with I believe Objective C and of course Python. Static typing
and Functional Programming seem to go hand in glove, cf. Haskell type
classes. Static OOP seems to invite inelegant and unsound compromises.

Donn Cave, do**@u.washingt on.edu

[Dan Perl]

"Donn Cave" <do**@drizzle.c om> wrote in message
news:1101273995 .954137@yasure. ..

Quoth "Dan Perl" <da*****@rogers .com>:
| "Donn Cave" <do**@u.washing ton.edu> wrote in message
| news:do******** *************** *@gnus01.u.wash ington.edu...
| > 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.
|
| You're right, I should have said statically typed instead of strongly
typed.
|
| But did you really mean "no one has figured out how to make *static*
typing
| really work with OOP" or did you mean *dynamic* typing?

Static. I figure dynamic & OOP get along fine -- as Smalltalk showed,
along with I believe Objective C and of course Python. Static typing
and Functional Programming seem to go hand in glove, cf. Haskell type
classes. Static OOP seems to invite inelegant and unsound compromises.
It's hard to argue against Smalltalk. I haven't used it for many years so I
don't remember it but it was THE language of choice for an OOP course I took
oh so many years ago. And I still see it mentioned as a model for OOP. I
never learned Objective C so I cannot argue with that either.
Unfortunately, as much as I am learning to like Python, I don't think I see
it as a picture perfect OOP language. It may be a controversial opinion but
I am not at all satisfied with encapsulation in Python (you cannot hide any
of a class's implementation) .

Can you elaborate on problems that static languages have with OOP? We have
been touching on parametric polymorphism and that is a valid point. I also
see multiple inheritance as being very poorly implemented in C++ and Java to
the point where books on C++ that treat the subject discourage you from
using it and Java has effectively designed it out of the language (you can
implement many interfaces but you can extend only one class). What do you
have in mind?

Dan
Donn Cave, do**@u.washingt on.edu

[Steven Bethard]

Donn Cave wrote:

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.

I'm not sure I follow your argument here. Java interfaces provide the
same sort of protocol-based typing as Python does (though of course you
have do declare interfaces everywhere to make them work this way).
Going back to my earlier Python example:

def process_rules(r ules):

.... for rule in rules:
.... print rule.name
....

the corresponding Java might look something like:

public interface Rule {
public Object getName();
}

public class RuleProcessor {
public void processRules(It erable<Rule> rules){
for (Rule rule: rules) {
System.out.prin tln(rule.getNam e())
}
}
}

Note that because Java is statically typed, you have to declare all the
appropriate interfaces: Iterable is in java.lang, and Rule is declared
above. In Python, the interfaces are implied by the use, and left
undeclared.

Of course, you have to declare your interfaces in a suitably generic
manner. I could have written this replacing Iterable<Rule> with
Collection<Rule > or List<Rule>, but Iterable<Rule> is the type that
makes the fewest commitments about the parameter and still allows me to
iterate over the Rule objects. Similarly, I could have written getName
to return a String, but by declaring getName with Object as a return
type, I make only the necessary commitment that getName returns a value.

The annoying thing, of course, is what you do when suddenly *one* use of
a Rule does require, say, a String result of getName:

public class OtherRuleProces sor {
public void processRules(It erable<Rule> rules){
for (Rule rule: rules) {
String[] s = rule.getName(). split('\\s')
}
}
}

Do I now declare a new interface for this Rule and add another
implements clause to all my classes that implement the original Rule as
well? Do I make the original Rule interface less general by changing
the return type from Object to String? It can get nasty rather quickly...

Python, of course, avoids this by not declaring types. =)

Steve

[Carlos Ribeiro]

On 23 Nov 2004 19:58:31 -0800, Mike Meng <me******@gmail .com> wrote:

I come from a very conservative background in software development
and strong checks are deeply rooted in my mind.
So do I, Dan.

I just can't imagine a `wild' object whose interface is valid can
truely do the right things. While in fact, when I typing this word, I
realize we can't ensure the internal protocol will be obeyed even when
the object IS-A base class instance.

Maybe it's time to rethink.

I understand, and I found myself using isinstance more often that I
would like to admit. Being trained in OO Pascal & Delphi it comes as
no surprise...
It seems to me the virtue of dynamic langauge is, if it looks like a
cat, it's a cat. But the problem is still there: how do you know what
it looks like before you treat it as a cat? isinstance(), , as Steve
state, is too rigid.

Time for adapt(), I think...

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmai l.com
mail: ca********@yaho o.com

[Dan Sommers]

On 23 Nov 2004 19:58:31 -0800,
"Mike Meng" <me******@gmail .com> wrote:

First off, I have only been following this thread on and off, so if I'm
repeating things, I apologize.

It seems to me the virtue of dynamic langauge is, if it looks like a
cat, it's a cat ...
Google for "duck typing."
... But the problem is still there: how do you know what it looks like
before you treat it as a cat? isinstance(), , as Steve state, is too
rigid.

You don't.

Python also takes a "we're all adults here" philosophy. If your API
specifies "cat," and I pass your function an "InterfaceAdapt er," it's
*my* problem.

If you're truly paranoid, make sure that your arguments at least have
the methods you're going to use:

# write 'foo' to the file-like object x; don't bother if x is not
# sufficiently file-like

def f( x ):
try: x.write
except AttributeError:
pass
else:
x.write( 'foo' )

# this works, too, but doesn't scale well (i.e., if 'foo' is some
# other non-trivial (maybe non-trusted) operation that can raise
# AttributeError) :

def f( x ):
try: x.write( 'foo' )
except AttributeError:
pass

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.

[Peter Hansen]

Mike Meng wrote:

It seems to me the virtue of dynamic langauge is, if it looks like a
cat, it's a cat.
I think this is more accurately expressed as "if it *acts* like
a cat, then you can treat it like a cat". Your version implies
that you really do care what it _is_, which goes back to the
static typing thinking again.
But the problem is still there: how do you know what
it looks like before you treat it as a cat? isinstance(), , as Steve
state, is too rigid.

The argument is that you probably don't really need to know
what it looks like *before* you try to use it, even if you
think you do. The cases where you really do are probably those
Alex Martelli's recipe (mentioned near the start of the thread)
is intended to help. (Specifically, avoiding the situation
where the object implements the required protocol only partially,
but you don't find that out until you've already started using
the object, possibly corrupting it in the process.)

-Peter

[Donn Cave]

In article <s4************ ********@rogers .com>,
"Dan Perl" <da*****@rogers .com> wrote
....

It's hard to argue against Smalltalk. I haven't used it for many years so I
don't remember it but it was THE language of choice for an OOP course I took
oh so many years ago. And I still see it mentioned as a model for OOP. I
never learned Objective C so I cannot argue with that either.
Unfortunately, as much as I am learning to like Python, I don't think I see
it as a picture perfect OOP language. It may be a controversial opinion but
I am not at all satisfied with encapsulation in Python (you cannot hide any
of a class's implementation) . Can you elaborate on problems that static languages have with OOP? We have
been touching on parametric polymorphism and that is a valid point. I also
see multiple inheritance as being very poorly implemented in C++ and Java to
the point where books on C++ that treat the subject discourage you from
using it and Java has effectively designed it out of the language (you can
implement many interfaces but you can extend only one class). What do you
have in mind?

I am really too unschooled in these matters to pursue that.
I have mentioned Haskell a couple of times, and that's my
perspective on static typing. I recommend it as an interesting
exercise: learn Haskell, find out what static typing is about.
It isn't perfect, but it's leagues ahead of C++ etc.

I don't have any beef with multiple inheritance, in fact the
notion of "mix-in" classes might have some potential to be the
basis for a more sound approach to OO.

Donn Cave, do**@u.washingt on.edu

[Steven Bethard]

Donn Cave wrote:

I don't have any beef with multiple inheritance, in fact the
notion of "mix-in" classes might have some potential to be the
basis for a more sound approach to OO.

The people that have a beef with multiple inheritance have it because
multiple inheritance can sometimes break encapsulation by forcing the
designer of a class to be aware of changes in the inheritance chain far
above its parents (even when no methods/attributes are added by the
change). A classic reference:

Snyder, Alan. "Encapsulat ion and Inheritance in Object-Oriented
Programming Languages"
http://www-plan.cs.colorado.edu/diwa...ers/snyder.pdf

Python tries to combat some of these problems with a good method
resolution order:

http://www.python.org/2.3/mro.html

I don't make enough use of multiple inheritance to ever have run into
these kinds of problems, but the literature in this area is enormous...

Steve

[Jacek Generowicz]

"Dan Perl" <da*****@rogers .com> writes:

Can you elaborate on problems that static languages have with OOP?

They make dynamic polymorphism impossible.

Which is why most object-oriented C++ programs are dynamically typed;
only the programmer is burdened with the work that the mostly-absent
dynamic type system should be doing.

Dynamic polymorphism crucially requires knowledge of the *run-time*
(dynamic) type of objects, in order to be able to dispatch to the
correct method. In C++ you turn your classes into dynamically typed
ones with the "virtual" keyword, which introduces a vtable and
run-time type identification (RTTI). As long as you are only
interested in calling methods which are declared in some base class,
this dynamic type systems looks almost satisfactory. As soon as you
want to use a method present in the subclass but not in the
superclass, it is up to you to faff around with dynamic_cast and
checking of the resulting pointer; all stuff which a dynamic type
system should be doing for you, but C++ makes you do yourself because
it pretends that your programs are statically typed when, in fact,
they are dynamically typed.