[Python-3000] Abilities / Interfaces

[Phillip J. Eby]

At 10:31 AM 11/22/2006 -0800, Guido van Rossum wrote:
>In *my* notion of abilities, this part being inspired by Zope
>interfaces, you can state after the fact that a particular class
>(which you didn't write) provides a given ability (which you didn't
>write either). I think it would also be great if we had "ability
>algebra" whereby you could state that a given ability A is composed of
>existing abilities A1 and A2, and every object or class that already
>has A1 and A2 will automatically be considered to have A.
>
>However, I do *not* want to go the way of duck typing here -- if an
>ability A claims that it is implemented by method foo(), and an object
>x has a foo() method but doesn't explicitly claim to have ability A
>(and neither does its class), then testing x for A should return
>false. I think this deviates from Haskell, which seems to be big on
>structural type equivalence (?).
>
>So I think Python needs to do its own thing here, to some extent.

Actually, you just described Haskell typeclasses.  :)  That is, they are:

1. Able to be specified after the fact
2. Are algebraically defined as sets of operations
3. Strongly typed based on functions

With respect to #3, I think you are confusing Haskell function names with 
Python method names.  Typeclasses also have one more ability that you 
didn't include above:

4. Able to provide implementations after the fact, not merely declarations

This is basically the same concept as adaptation and generic functions, so 
that you can not only *declare* that a type meets an interface, but also 
provide a way to make it work.

So, we are in agreement on some basics, I think.  I am mainly concerned 
that we do not treat interfaces as collections of method names, rather than 
collections of operations.  (Attributes can be considered operations to 
read, write, or delete them, and in many cases you will want to specify 
those operations individually in an interface/typeclass).

In Haskell, however, it is not that common for ordinary code to define or 
use typeclasses, since direct use of the operations (e.g. len()/iter() 
equivalents) normally suffices to imply the typeclass(es) involved.  Also, 
like Java, Haskell selects overloaded implementations based on their 
argument type, so you don't write "if isinstance" tests either.

Generics reduce the need for type testing and explicit interfaces, since 
you can just use an operation rather than needing a method (as in Haskell) 
or you can define overloads to select an implementation (as in Java).

In Python, however, interface libraries have historically treated their 
operations as simply a bag of method names and call signatures, which 
doesn't allow algebraic operations and introduces the need for explicit 
adapter types.  In contrast, an operation-based approach (where interfaces 
are collections of first-class "operations" of some kind, that can be 
recombined to create new interfaces) allows both interface algebra and 
*automatic* adapter generation (as described in my "monkey typing" proposal 
early last year).