[Python-3000] Abilities / Interfaces: why not adapt()?

[tomer filiba]

[GvR]
> I'd like to have a discussion of abilities and interfaces but right
> now I don't have time -- maybe tomorrow. I see Andrew's proposal as
> mostly isomorphic to Zope's notion of interfaces, but the new
> terminology may make it possible to clarify certain distinctions
> better, e.g. the distinction between a class that provides an ability
> to its instances, and the abilities that an instance has.

[Antoine Pitrou]
> class Complex:
>    __implements__ = (Number,)
...
> So to sum it up, to know whether an object-or-class implements a given
> interface, you could call a standard function
> implements(obj, interface), which in turn would call
> interface.__implemented_by__(obj). It's up to each interface to decide
> what breadth of tests it wants to perform, although it would be
> practical to fallback on a default implementation (in the Interface base
> class common to all interfaces) which just checks for presence of the
> interface in obj.__implements__.
-------------------------------------------------------------------------------

it reminds me greatly of the old (rejected) mechanism suggested by
the adaptation PEP... only weaker.

http://www.python.org/dev/peps/pep-0246/

these approaches only *check* a type for conformance with some
interface, but the adaptation introduced a new way to look at
interfaces/protocol/conformance at all:

instead of asking "does object X supports interface Y?", adapt()
attempts to *give* you an object X that supports interface Y.

adaptation is much more capable ("don't complain, do something
about it") and reflective (both the protocol and the instance can
perform the adaptation) so you don't have to explicitly inherit
from many base classes or interfaces.

i'm very +1 on reviving adapt() and dropping all those "i want
strongly-duck-typed interfaces in python" talks.

give power to the duck -- adapt can do it all.


-tomer