[Python-3000] Sane transitive adaptation

[Phillip J. Eby]

At 01:39 PM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/7/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Mostly just the API docs:
> > http://peak.telecommunity.com/protocol_ref/module-protocols.html
>
>I just finally found this too. PJE's website is really a confusing
>maze; the only *source* for PyProtocols I've found so far is a CVS
>repository that seems to be telling me not to use it because it's been
>converted to SVN. But the SVN repository doesn't seem to have
>PyProtocols, only PEAK. :-(
>
>Anyway, the quote at the top of that page also explains why I'm still
>grappling for use cases:

Don't bother - PyProtocols has few use cases that aren't better served by 
overloadable functions, even of the single-dispatch kind.

The use cases for overloadable functions, in turn, tend to break down into 
single dispatch, double dispatch, and predicate dispatch.  I haven't 
actually encountered a use case for dispatching on 3 or more arguments that 
didn't also require some other kind of predicate besides 'isinstance()'.


>  I don't think of my own use of Python as that
>of "an integrator, someone who is connecting components from various
>vendors." Or at least, that's not what it feels like. I write plenty
>of code that uses multiple 3rd party libraries; for example my current
>Google project blends Django templates, wsgiref, a home-grown Perforce
>wrapper, a Google-internal database-ish API, and some other minor
>Google-specific APIs. But it doesn't *feel* to me like there's a need
>to adapt one package's API to that of another; instead, my application
>is in control and makes calls into each package as needed.

Those are mostly libraries, not frameworks, and for the most part you're 
not *integrating* them.  You're not trying to make Perforce store 
information in your database, or to put a database API over Perforce, for 
example.


>  I wonder if
>it would feel different to you, Phillip and Alex, and I'm just not
>seeing the opportunities for adaptation, or if it really does depend
>on the typical application.

It depends mainly on the library.  A lot of PEAK is there because existing 
Python libraries or frameworks simply weren't extensible or configurable 
enough for the tasks my team was doing at Verio.  It was very, very 
frustrating, because there were a lot of libraries that were almost perfect 
- except for some dependency on an internal type that couldn't be mixed 
with the types from some other library.  Source patching or monkey patching 
just didn't seem like a viable solution for a lot of these problems.

My later work on setuptools was inspired by realizing that the real answer 
wasn't reinventing competing wheels, but rather to build more roads so that 
more people would actually use the wheels and complain to the wheels' 
makers if they weren't round enough.  :)


>That's not the feeling that occurred to me when I was writing my
>Google project (see above). I can think of a few things that were
>inflexible. For example, the version of Django I'm using doesn't let
>you override how it searches for templates, and I had to monkey-patch
>the implementation to allow requesting the template source from an
>abstract API that gets it from a zip file, rather than going to the
>filesystem directly. But I don't see how adaptation or extensible
>functions would have helped.

Well, it would've given you a less obscure way of monkeypatching, since it 
would be part of the language.  And, the authors would be more likely to 
think about "what functions might people want to overload?" and therefore 
include choke points of this kind.  If everything's overloadable, then 
offering users choices is cheap.

Here's an example of a problem I ran into: pydoc and epydoc hate things 
with custom metaclasses, callable objects not of FunctionType or 
MethodType, and often any descriptor that wasn't a built-in type (like 
classmethod, property, etc.).  They both have big if-then trees dispatching 
on type.  So, I simply couldn't use them to generate documentation, even 
though everything *else* about them was great, without extensive patching 
(because the trees were spread out everywhere in their code bases).

If overloading was in the language, however, the One Obvious Way to 
implement those libraries would've been overloading -- which means they 
would have been extensible as a *natural side effect*.

So this is the way in which overloading will be *good* for the language, 
because in this case, the right thing for the library user will become the 
right thing for the library author as well.