[Python-Dev] Proposed Mixins for Wide Interfaces

Guido van Rossum guido@python.org
Tue, 03 Sep 2002 13:50:31 -0400

> How about adding some mixins to simplify the
> implementation of some of the fatter interfaces?

Can you suggest implementations for these, to be absolutely clear what
you mean?

> class CompareMixin:
>     """
>     Given an __eq__ method in a subclass, adds a __ne__ method
>     Given __eq__ and __lt__, adds !=, <=, >, >=.
>     """

What if the "natural" thing to implement is __le__ instead of __lt__?
That's the case for sets.  Or __gt__ (less likely)?

> class MappingMixin:
>     """
>     Given __setitem__, __getitem__,  and keys,
>     implements values, items, update, get, setdefault, len,
>     iterkeys, iteritems, itervalues, has_key, and __contains__.
>     If __delitem__ is also supplied, implements clear, pop,
>     and popitem.
>     Takes advantage of __iter__ if supplied (recommended).

Does that mean that if you have __iter__, you don't use keys()?  In
that case it should implement keys() out of __iter__.  Maybe this
should be required.

>     Takes advantage of __contains__ or has_key if supplied
>     (recommended).
>     """

Let's standardize on __contains__, not has_key().  I guess you could
provide __contains__ as follows:

  def __contains__(self, key):
      except KeyError:
          return 0
          return 1

I don't mind if there are some recursions amongst the various
implementations; if you don't supply the minimum, the implementation
will raise "RuntimeError: maximum recursion depth exceeded".

> The idea is to make it easier to implement these interfaces.
> Also, if the interfaces get expanded, the clients automatically
> updated.  

A similar thing for sequences would be useful too, right?

--Guido van Rossum (home page: http://www.python.org/~guido/)