Python 1.6 The balanced language

[Alex Martelli]

"Neel Krishnaswami" <neelk at brick.cswv.com> wrote in message
news:slrn8r53ki.bfu.neelk at brick.cswv.com...
    [snip]
> > If by subtyping you mean the java 'implements', then, yes.  But to
> > call the signature-based polymorphism of Python "subtyping" is
> > starting to stretch the meaning of the word -- yet, it's at least
> > equivalent to what interface+implements lets you do, modulo
> > the compile-time checks.
>
> Not really. If you create a class (call it Foo) with all the methods
> of an interface (call it Bar) but you don't specifically declare the
> "implements" relation, then you can't use Foo in the place of a Bar.
> The classes that implement an interface are all subtypes of the type
> the interface creates, and no other classes are subtypes of that
> interface.

Right -- in Java; in Python, OTOH, you work with signature-based
commonality (no specific declaration of 'implements').  I'm saying
that signature-based commonality lets you do _at least as much_
as subtyping-via-implements, except the compile-time checks.  So,
OO does *not* require subtyping (don't start claiming that compile
time checking is a prereq of OO, or you'd end up excluding CLOS,
Smalltalk, ... :-) -- QED.


> > I say that OO == polymorphism, aka, runtime dispatching.  If it's
> > done through subtyping, signatures, prototypes, etc, is quite a
> > secondary issue.
>
> Mostly, yes. I would want to distinguish parametric polymorphism (a la
> ML) from the dynamic method lookup in OO languages. (It's possible to
> combine both, of course, as in Python and other dynamically typed
> languages.)

Compile-time parametric types (as in ML, Sather, Eiffel, C++) are
indeed different from runtime dispatching (which need not imply
much in terms of 'dynamic lookups', in languages sufficiently
rigid to allow vtable-like implementation).  In the C++ and other
communities, 'polymorphism' equates to dynamic dispatching,
while 'genericity' is used for compile-time parameterization.


> > Similarly, say the Cecil authors, "Cecil uses a classless
> > (prototype-based) object model" (e.g., cf
> > http://www.objs.com/x3h7/cecil.htm).  And one must not confuse
> > argument-specializers, with type-declarations (the latter do not
> > affect method-lookup in Cecil).
>
> What I mean by "type" is equivalent to the Cecil "isa" keyword. This
> is just the descendant-of relation.

So, it's not what Cecil calls type (which is far closer to the classic
notion of 'type'!).  And, since in the real world being a descendant
IS a rather permanent situation, I don't particularly like naming
such a transient relation as 'descendant-of'; 'delegates-to' seems
far closer to the mark.

> I disagree quite strongly. The notion of type is extremely useful even
> in prototype based languages. It allows us to formalize the notion of
> (for example) mode switching, which is an extremely elegant style of
> programming.

The notion of delegation is indeed very useful; what I'm disputing
is that it's particularly useful to confuse it with (what Cecil calls,
and is classically known as) 'type'.

Many Pythoneers dislike the type/class distinction that holds in
Python, and it may be a bother when writing a C extension, but
I think it's useful at the Python-programming level.  An instance's
class is not its type...


Alex