[Python-3000] PEP 3133: Introducing Roles
steven.bethard at gmail.com
Mon May 14 08:08:08 CEST 2007
On 5/13/07, Collin Winter <collinw at gmail.com> wrote:
> PEP: 3133
> Title: Introducing Roles
> * 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.
> * Abstract base classes, by contrast, are a way of reusing common,
> discrete units of implementation.
> 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: ::
> 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::
any better than::
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?)
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
More information about the Python-3000