PEP 245

[Alex Martelli]

"Alex Shindich" <alex at server01.shindich.com> wrote in message
news:mailman.986188563.4299.python-list at python.org...
> On Mon, 2 Apr 2001, Carlos Alberto Reis Ribeiro wrote:
>
> > At 16:29 01/04/01 -0700, Alex Shindich wrote:
> > >I do not want to restart the whole discussion on the difference between
> > >base classes and interfaces, but I am of the opinion that they both
> > >represent an is-a relationship.
> >
> > Almost... base classes represent an "is-a" relationship. Interface
> > implementation represent an "work-as" relatioship (if there is anything
> > like this :-).
> Whatever... I don't really see the difference. The client code doesn't
> know and shouldn't know the difference between the two.

Inheritance may generally mean "is (partly) implemented in terms of" -- in
C++, one normally uses _private_ inheritance for this specific purpose, but
in Python there is no such distinction.  Of course client code doesn't
care about what is implemented in terms of what else -- this means it
doesn't (shouldn't) generally care about inheritance relationships among
the stuff it uses.  *Implementing an interface* is what client code's
interests should focus on -- period.

The pure "is" ("the IS of identity", to quote Korzybski) is a red herring.

> more complex? Besides, developers with Java and/or COM experience will be
> confused with the proposed implementation for the interfaces, as it
> doesn't offer compile time checking.

COM, per se, has no concept of 'compile time' either.  Among the languages
best supporting COM are some (such as Python:-) which do very little, if
anything, "at compile time".

A COM object is asked *at runtime* whether it can support/"adapt to" a
certain interface; it may accept (by supplying an implementation of
that interface -- which it may perfectly well choose to provide on the
fly at runtime, that's what "tear-off-interfaces" are all about for
example) or refuse.  The set of supported interfaces, in COM, is also
intertwined with an object's _identity_ (if an object with a given
identity has ever denied supporting an interface it must NEVER 'change
its mind' and start supporting it; if an object has ever provided
an interface it must forevermore be ready to support it, and adapters
for various interfaces coming from the same object must obey rules of
reflexivity and transitivity as well as provide a bitwise identical
response if asked for the specific interface "IUnknown", which stands
for the whole object's identity) -- which is why COM has sprouted
other secondary ways of asking for adapters (IServiceProvider springs
to mind) which are not subject to such object-identity-constraints.

In Python's case, we don't share the needs and design constraints which
led to COM's rules (proxying, marshaling...), so there is no need to
impose identity-constraints and the resulting complications (even today,
Python allows an object to keep identity BUT change behavior, e.g. by
changing its __class__).  But that has really nothing to do with
compile-time vs run-time.


> I am just worried that the language will be polluted with a bunch of
> foreign constructs from other languages. Not that those constructs are
> bad, but they do not work as well in the dynamic systems such as Python.

I see nothing in the interface-adaptation PEP that can be said to
be borrowed from other languages (even if one counted COM as "a
language", which of course it isn't -- it's an object-model, which
can be, and is, implemented by a huge variety of languages), and
most particularly nothing that somehow depends on 'staticity' vs
Python's 'dynamism'.


Alex