[Python-3000] An introduction to ABC's
Phillip J. Eby
pje at telecommunity.com
Tue Apr 17 18:46:38 CEST 2007
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
More information about the Python-3000