[Python-3000] Sane transitive adaptation (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sat Apr 8 23:22:35 CEST 2006

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/protocolref/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

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.

More information about the Python-3000 mailing list