[Python-Dev] Single- vs. Multi-pass iterability

[Alex Martelli]

On Monday 15 July 2002 06:06 am, Clark C . Evans wrote:
	...
> Although this is a nice question to ask; as a programmer with 10+
> years of building components, and using other's components to
> build larger applications I often ask a similar but related question:
>
>    Well, if it ain't a Thymagig, where is the
>    wrapper so I can treat it like one?
>
> It is this second question that the Object Adaptation PEP is based.

Right.  The concept of adaptation definitely comes from the Components
world, where "is-A" is a dirty word.  High time the Objects world listened:-).


> Speaking of which, I personally don't feel that interfaces
> is the way to go...  there are many reasons why I'm using Python
> and not using Java.  Interfaces are too inflexible and often times
> can cause more headaches than they save with additional typing.

A suitably Pythonic approach to interfaces won't cause any more
headaches than, say, booleans (check Google for the firestorm that
the Booleans PEP caused...:-).  We do need the CONCEPT of an
interface, just as we need the concept of true and false values.

Whether reifying the concept into a type or language-blessed
category buys you more than it costs -- much depends on how it's
done.  Personally, I'd rather have that superset of "interface" that
is known in Haskell as a "typeclass" -- and I'd settle for that middle
ground that is known in C++ or Java as an "abstract class".  If
interfaces/typeclasses/&c came with Eiffelish 'contracts', so much
the better.  But it's all in the narrow range between -0 and +0 for me.

> especially for Python.   For example, interface inheritance is
> one of those bits of baggage (that others may disagree with me on).
> Interface inheritance is one of those "givens" that one must do to

I'm not sure what you mean by "interface inheritance".  The ability
to define an interface by adding some stuff to another interface --
that's the only sense in which one could possibly speak of such
a thing in Java, say -- is extremely convenient but not a must-do...
COM manages without, not conveniently but OK all the same.  I
suspect you mean something quite different.

> do interfaces right.  Interface inheritance isn't needed.  Why?
> Mix-ins are far more powerful mechanism as they make you think about

Mix-in inheritance is basically about _implementation_.  Just like
most inheritance in Python most of the time -- issubclass, isinstance
and exception handling being the exceptions to the 'most'.  Nobody's
planning to take it away from Python, anyway.

> operations which are othogonal to each other.  You think that
> interface inheritance helps, but in my experience it just screws
> with your thought process... ;)

I've had no particular trouble designing interfaces either in Java,
with interfaces able to inherit from each other, or in COM, without
such convenience.  In the latter case one ends up with a bit of
copy and paste, not pleasant, but WTH.  I see it mostly as a bug
in COM's MIDL and supporting tools/wizards -- they let you ask for
interface inheritance even though the underlying object model does
not support it (by doing the copy-and-paste implicitly) but then don't
go all the way (e.g., they'll freely and erroneously reuse in the
inheriting interface some method dispatch-IDs that the interface
inherited-from has already assigned -- eccch).


The big question is rather: given that Isub inherits from Isuper,
does any object implementing Isub also implicitly implement Isuper?

That's the object-philosophy, where inheritance is thought to reflect
deep IS-A relations.  It's NOT the component-philosophy, where
inheritance is an implementation-convenience detail.  I much prefer
the component-approach, where my component has full control, if
it wants to, on exactly what interfaces it exposes.  This lets you
factor out any commonality between interfaces without giving any
actual reality to the factored-out common subset -- it can even stay
an "abstract interface" that no object actually supplies, if you want.

I do think it's a respectable thesis, though I don't agree with it, that
the OO rather than component approach to inheritance is, while less 
flexible for advanced uses, easier to use -- made simpler by conflating
different concerns (how is this interface exactly -- what set of interfaces
can I get from this object) into one powerful general concept.  I think
it's harder when you have to learn that said "one powerful general
concept" has several rather separate uses, and the ability to have some
specific uses fall in the gray zone between the typical use cases does
not exactly help learning and understanding, either.  But I do think that
quite a reasonable debate could be held about this.


> Anyway, I'm so glad that Alex has taken up the cause; I'm not all
> that actively involved in Python internals... but as a user I can't
> advocate more for something like this.  Alex, I'm delighted if
> you would take ownership of the PEP.

OK, thanks!


Alex