[Python-3000] PEP 3133: Introducing Roles

[Steven Bethard]

On 5/13/07, Collin Winter <collinw at gmail.com> wrote:
> PEP: 3133
> Title: Introducing Roles
[snip]
> * Roles provide a way of indicating a object's semantics and abstract
>   capabilities.  A role may define abstract methods, but only as a
>   way of delineating an interface through which a particular set of
>   semantics are accessed.
[snip]
> * Abstract base classes, by contrast, are a way of reusing common,
>   discrete units of implementation.
[snip]
>   Using this abstract base class - more properly, a concrete
>   mixin - allows a programmer to define a limited set of operators
>   and let the mixin in effect "derive" the others.

So what's the difference between a role and an abstract base class
that used @abstractmethod on all of its methods? Isn't such an ABC
just "delineating an interface"?

> since the ``OrderingMixin`` class above satisfies the interface
> and semantics expressed in the ``Ordering`` role, we say the mixin
> performs the role: ::
>
>   @perform_role(Ordering)
>   class OrderingMixin:
>     def __ge__(self, other):
>       return self > other or self == other
>
>     def __le__(self, other):
>       return self < other or self == other
>
>     def __ne__(self, other):
>       return not self == other
>
>     # ...and so on
>
> Now, any class that uses the mixin will automatically -- that is,
> without further programmer effort -- be tagged as performing the
> ``Ordering`` role.

But why is::

    performs(obj, Ordering)

any better than::

    isinstance(obj, Ordering)

if Ordering is just an appropriately registered ABC?


(BTW, Ordering is a bad example since the ABC PEP no longer proposes
that.  Maybe Sequence or Mapping instead?)


STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy