[Python-3000] Need help completing ABC pep

[Phillip J. Eby]

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.