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.

[Christophe Cavalaria]

Jacek Generowicz wrote:

"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.

If your programs need that much dynamic_cast to work, then your programs are
bad. Besides, it's easy to do a 'safe' dynamic_cast, just assert that the
pointer you get isn't 0 after the cast.

[Jacek Generowicz]

Christophe Cavalaria <ch************ *@free.fr> writes:

Jacek Generowicz wrote:

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

Can you elaborate on problems that static languages have with OOP?
They make dynamic polymorphism impossible.

Besides, it's easy to do a 'safe' dynamic_cast, just assert that the
pointer you get isn't 0 after the cast.

Yes, you can "easily" do the work that the absent dynamic type system
should be doing for you (and Turing equivalence tells us that that we
can implement a decent dynamic type system as well). The fact remains
that the objects *are* *dynamically* typed, even though the language
claims to be statically typed. The fact that statically typed
languages feel the need to introduce dynamic typing (however poorly
supported it may be) in order to support OOP, points to the fact that
static type systems DO have problems with OOP, which is what the
question was about.

Specifically, dynamic polymorphism is impossible without dynamic
typing.

[Donn Cave]

Quoth Jacek Generowicz <ja************ **@cern.ch>:
[ ... re C++ casting to subtype ]
| Yes, you can "easily" do the work that the absent dynamic type system
| should be doing for you (and Turing equivalence tells us that that we
| can implement a decent dynamic type system as well). The fact remains
| that the objects *are* *dynamically* typed, even though the language
| claims to be statically typed. The fact that statically typed
| languages feel the need to introduce dynamic typing (however poorly
| supported it may be) in order to support OOP, points to the fact that
| static type systems DO have problems with OOP, which is what the
| question was about.
|
| Specifically, dynamic polymorphism is impossible without dynamic
| typing.

Given a model for polymorphism that means smuggling an object
around wrapped in some degree of mystery about its type, elegant
and sound static typing does seem unlikely. But C++ and its
descendents have always been easy targets. Would you happen to
know something about how Objective CAML's OO system approaches this?

I see in the on-line documentation this paragraph:

Be aware that subtyping and inheritance are not related. Inheritance
is a syntactic relation between classes while subtyping is a semantic
relation between types. For instance, the class of colored points could
have been defined directly, without inheriting from the class of points;
the type of colored points would remain unchanged and thus still be a
subtype of points.

http://caml.inria.fr/ocaml/htmlman/manual005.html

I'm thinking that this might be more or less typical of academic
ideas about OO typing, and it seems conceptually appealing. I
don't know the details though.

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

[Dirk Thierbach]

Donn Cave <do**@drizzle.c om> wrote:

Quoth Jacek Generowicz <ja************ **@cern.ch>: Given a model for polymorphism that means smuggling an object
around wrapped in some degree of mystery about its type, elegant
and sound static typing does seem unlikely. But C++ and its
descendents have always been easy targets. Would you happen to
know something about how Objective CAML's OO system approaches this?
In several ways: First, by using parametric polymorphism (not defined
as in this thread above, but by allowing "type variables" (type parameters)
which are applied as necessary, both in every expression, and in
object types. Second, by using so-called "row types", i.e. types
for incomplete records (in OCaml, they are denoted by the trailing dots
in a type like < get_x : int; set_x : int -> 'a; .. > ).

Together, they allow you to statically type most of the usual applications
of inheritance, virtual methods, etc. There used to be an somewhat
more contrived example in the OCaml manual with a subject/observer
pattern, virtual methods, and both abstract and concrete classes,
but I think they removed that some time ago.

As for

Specifically, dynamic polymorphism is impossible without dynamic
typing.
I haven't heard the term "dynamic typing" in this context, and I think
it's a bit unfortunate, because it's not "typing" in the usual
sense. If Jacek just means virtual methods, as in
In C++ you turn your classes into dynamically typed ones with the
"virtual" keyword, which introduces a vtable and run-time type
identification (RTTI).
that's easy to do in OCaml, and it also works in the type classes
of Haskell. The problem Jacek describes here:
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;

is solved by keeping the parametric type "uninstantiated " as long
as possible, and instantiate it with the concrete type only when
it is clear that you really need the method present in the subclass.
Or, you handle this with the row types.

It does not work in every case one can think of right from the start
(you have to be able to statically guarantee that you have really the
subclass to work with at this point of your code, and not the
superclass), so you might to rewrite your code a bit to make it
work. Maybe it's easier to see if we do concrete examples.
I see in the on-line documentation this paragraph:

Be aware that subtyping and inheritance are not related. [...] I'm thinking that this might be more or less typical of academic
ideas about OO typing, and it seems conceptually appealing. I
don't know the details though.

The "inheritanc e is not subtyping"-motto is somewhat orthogonal to
this issue. It comes originally from a paper by Benjamin Pierce, with
IIRC the same title. If you think this concept through, it really helps
to sort out some of the confusion that comes with the "usual" OOL's
like Java and C++.

- Dirk

[Alex Martelli]

Peter Hansen <pe***@engcorp. com> wrote:

> 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.)

Exactly. The recipe's still in the CB 2nd edition (which I should be
editing right now instead of doing usenet, with deadline so terribly
close and lots of enhancements left to do, but hey, it IS 1:30 AM, I
deserve a little break;-).

The right solution is adaptation (PEP 246, Eby's PyProtocols, etc), but
until we can convince Guido of that, so that adaptation becomes
widespread, duck typing, and occasionally (when needed) "accurate LBYL"
remain the best approach.

And don't forget unit-tests -- see Robert Martin's now-famous article at
http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .
Alex

[Alex Martelli]

Dan Perl <da*****@rogers .com> wrote:

I have a question here, as we are discussing now protocol interfaces vs.
inheritance. Is using a class that implements a protocol without inheriting
from a base class still "polymorphi sm"?
``still'' is inappropriate here. It is _fully_ polymorphism, of course.
It's known as signature-based polymorphism. C++ has it in templates,
only, where it's the basis of the whole power of the standard library
containers, algorithms, iterators, etc. Python has it everywhere,
except where some coder breaks everything with 'isinstance' or the like.
There are probably many definitions
for polymorphism and probably all those definitions can be interpreted in
such a way that they accept also protocols. But what I would like to hear
Otherwise they're very broken and useless definitions.
is what is the general opinion of people who use python. I am biased
because I come from a C++ and Java background and I am still used to a
certain practical meaning for "polymorphi sm".
One that doesn't apply to C++ templates?!
But it's beginning to dawn on
me that it is only a bias and polymorphism does apply also to python
protocol interfaces. Is that generally accepted?

Yep.
Alex

[Alex Martelli]

Christophe Cavalaria <ch************ *@free.fr> wrote:

If your programs need that much dynamic_cast to work, then your programs are
bad.
Wrong. Look at the absolute mess that the Visitor design pattern is,
and how Robert Martin made it much less horrible by turning it into
Dynamic Visitor -- which needs so much dynamic_cast it hurts.

In Java, you're dynamic_cast'in g all of the time in a totally obscure
way, each time you're pulling stuff out of a containter.

SomeSillyType foo = (SomeSillyType) (mycontainer.ge tsomething());

since the container's method returns Object, the cast is dynamic -- only
checked at runtime. C++, and the latest Java, give up OO in favour of
another paradigm (generic programming) to deal with this, and if this
isn't an admission that their "static" (ha!) typesystem doesn't work
with OOP properly, I don't know what would count as one.
Besides, it's easy to do a 'safe' dynamic_cast, just assert that the
pointer you get isn't 0 after the cast.

or catch the dynamically generated exception in Java's case, sure. You
can "easily" implement what a decent language would have in the first
place... except that co-variance and counter-variance continue to dog
every effort to make a decent "static OOP typesystem", of course...:-)
Alex

[Dirk Thierbach]

Dirk Thierbach <dt********@gmx .de> wrote:

Donn Cave <do**@drizzle.c om> wrote:

Quoth Jacek Generowicz <ja************ **@cern.ch>:

Specifically, dynamic polymorphism is impossible without dynamic
typing.

I haven't heard the term "dynamic typing" in this context,

Sorry, that should have been "dynamic polymorphism".

- Dirk