[Python-3000] An introduction to ABC's (original) (raw)

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 hasattr().)

More information about the Python-3000 mailing list