[Python-3000] Abilities / Interfaces

Bill Janssen janssen at parc.com
Wed Nov 22 18:32:46 CET 2006


Guido wrote:
> On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> > Actually "ability" is more general than "interface", because interface
> > implies two things talking to one another.  Some Zope uses of "interfaces"
> > don't include any actual "interfacing" at all, so to me your examples
> > actually support calling them "abilities" rather than "interfaces".
> 
> I like this line of reasoning. It makes a lot of sense.
> 
> I'm still torn because I also like using familiar terminology or
> syntax even if I have to give it new semantics; Python is all about
> that! It can get tedious to have to explain to new users "well, an
> assignment is known as PUT, and a variable is called a location, and
> subroutines we call a HOW'TO, and strings we call texts" (as was the
> case for ABC, Python's ill-fated predecessor which invented "optimal"
> terminology in a vacuum).
> 
> But for the time being I'd like to try out this new word and see how it fits.
> 
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

I see nothing wrong with defining "empty" ABCs to indicate abilities
rather than interfaces.

   class WellTested (Ability):
     """Indicates that the type has passed the QA process"""
     pass

   class TestedNumber (Number, WellTested):
     ...

The whole point of using classes instead of just looking at the
methods is to be able to indicate semantics that the programming
language can't express.  (Well, along with improved simplicity and
improved communication and faster type-checking :-).

Bill


More information about the Python-3000 mailing list