[Python-3000] An introduction to ABC's

[Phillip J. Eby]

At 12:18 AM 4/17/2007 -0700, Talin wrote:
>The real question to ask is - what is the 90% solution? In other words,
>what is the simplest mechanism that covers 90% of the use cases, while
>allowing the other 10% of use cases to handled by allowing the
>application programmer to extend the system or add a layer on top of it?

That's easy, actually.  If you have a generic function, then you can add an 
overload for your specific type that does whatever you need it to do.

In other words, the proper discipline for inspection is to place the 
inspection within a generic function that your clients can add overloads to.

Note, by the way, that even fairly sophisticated generic function 
implementations are pretty trivial in Python.  Take a look at Guido's 
multi-dispatch prototype for Py3K, or the simplegeneric package on the 
Cheeseshop, or even the generic function implementation in pkgutil (Python 
2.5 and up).

That makes them a pretty good 90% solution, especially since they don't 
even *need* ABC's for this to work.  It's quite okay to define methods for 
concrete types and let the user decide whether their implementation 
suffices, doing something like:

     thefunction[mytype] = thefunction[othertype]

to say that *in the context of thefunction*, mytype is an adequate 
replacement for othertype.

(ABCs and interfaces have the problem, however, of being 
context-free.  Thus, the proper discipline for interfaces is to use 
adaptation and to have "one interface per use case", rather than "one 
interface per concept".)


>Thus, if someone has a use case that requires that objects be
>dynamically reclassified at runtime,

Dynamic reclassification isn't the real problem, it's just as much a 
problem for static classifications that *disagree with the receiver's 
choice of inspection*.  Pydoc and earlier Zope versions have this problem 
all over the place, no dynamic reclassification necessary.

The key principle here is that the *client* should get to decide what 
happens to their objects, because the author of the client is the only one 
who knows what he or she *intends*.  The author of the library cannot 
*know* the use cases of his or her users, and should therefore refuse the 
temptation to guess.

Generic functions allow library authors to provide *overrideable defaults*, 
in place of *unchangeable guesses*.  (Which is what if/then tests are, 
regardless of whether they use ABCs, concrete types, interfaces, or even 
hasattr().)