[Python-3000] Need help completing ABC pep (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sat Apr 21 18:43:17 CEST 2007

At 08:06 AM 4/21/2007 -0700, Guido van Rossum wrote:

On 4/21/07, Phillip J. Eby <pje at telecommunity.com> wrote: > At 12:33 PM 4/20/2007 -0700, Talin wrote: > >Additionally, the need to override the classification of an > >object can be done more cleanly using generic functions: In the simplest > >case, one can define a "category membership" generic function that > >simply returns False in the base implementation, and then provide > >overrides that return True for any classes of interest. > > Yes, but that's sort of like saying it's better to point a pistol at your > foot than a shotgun. :) Explicitly testing category membership is a bug, > not a feature; you're far better off defining an overload to do whatever it > was you were going to make the if-then test do.

I don't believe that's always true. I can imagine use cases where, if I were writing it in an if-then-else fashion, I'd be writing the same if-test several times as part of a particular algorithm, without having an easy way to refactor the algorithm so that there's only one place testing it. Turning each place where the if-test is repeated into a different GF might be a wasted of time; turning just the test into a GF seems just right. (IN THAT PARTICULAR CASE.)

I understand the motivation; it's just been my personal experience that when I encounter such a case, there are always other parts of the library that will need those "different" GF's, because they end up being expressive and relevant to the problem domain of the library as a whole. Those "different" GF's then become a clean specification of the interface(s) required by the library.

For example, pydoc frequently asks whether something 'isroutine()' or 'ismethod()', but if it were factored to use elementary GF's instead, we would have things like 'getsignature()' and 'getmembers()' instead, and it would then be straightforward to document how to make a new kind of object work with it. (i.e. if you have members, implement a getmembers() overload, if you're callable, implement a getsignature() overload, etc.)

So, if you're writing any sort of library, you will usually get a solid payoff from doing factoring these primitives, given the high probability that your own library will use them more than once, and the ease of documenting the idea of having a call signature vs. trying to explain (or making your users figure out) the nine jillion consequences of having 'isroutine()' return True. I suppose you could say it's a tradeoff of "wasting" your time, vs. wasting your users' time.

Note that I don't object against the idea that usually a GF is better; I just don't think it always is so.

I can certainly conceive that there might be an exception, I just have yet to encounter it. But then, my focus is nearly always on library development, where my "customer" is the library's user. Within that niche, I think there's a much bigger case to be made that it is at least nearly always so.

More information about the Python-3000 mailing list