[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 07:22 AM 7/19/2007 -0700, Guido van Rossum wrote:
>On 7/19/07, Aurélien Campéas <aurelien.campeas at logilab.fr> wrote:
> > I would have liked to have input on this from other people using
> > RuleDispatch features also (doesn't one of Django/Turbogears project
> > use them extensively ?). Just so the BDFL & lieutenants don't argue
> > too much in the direction of 'the community has no experience with
> > these things'. I think (wishfully ?) a sizeable, if not big, part of
> > the python *user* community is knwoledgeable about it. These people do
> > not necessarily express themselves there.
>
>Thanks for posting. It's been excruciatingly hard to find anyone
>besides Phillip interested in GFs or able to provide use cases. For me
>they're mostly still something theoretically interesting from other
>languages, like continuations. Maybe you can round up some more users?

About a month ago, googling PEP 3124 turned up a handful of blog 
posts in support.  I also got a few private emails of support.  The 
blog posts weren't from anybody I know or who are past users of my 
libraries, AFAICT, and at any rate aren't the same people who emailed.

My simplegeneric package has hundreds of downloads logged at the 
Cheeseshop -- about 1/8th as many as wsgiref, if that gives you any 
idea of relative popularity.

RuleDispatch isn't on the Cheeseshop, so I don't know how many people 
are using that.  But the people that are, are very 
enthusiastic.  During the time period when RuleDispatch wasn't 
working properly on Python 2.5 yet, I got fairly regular emails 
asking when it would.  :)  RuleDispatch uses my DecoratorTools 
package, whose 1.4 version had over 8000 Cheeseshop downloads (more 
than double wsgiref), and I believe that those are mostly due to 
TurboGears' use of RuleDispatch (as well as direct use of DecoratorTools).


>FWIW, I think the Turbogears use you're thinking of is jsonify, a GF
>for converting arbitrary Python data into JSON (JavaScript Object
>Notation). But I'm not aware of it using any of the advanced features
>-- it seems to be using just the basic facility of overloading on a
>single argument type, which could be done with my own "overloading"
>example (see the Python subversion sandbox).

Actually, for that use case even simplegeneric would suffice, but at 
the time JSONify was written, it didn't exist yet.

By the way, I recently came across a use case for @around that I 
hadn't mentioned before.  I'm in the process of re-implementing 
RuleDispatch's expression features in PEAK-Rules, and as I was 
defining the rules for intersecting logical conditions, it occurred 
to me that you could define intersection in terms of 
implication.  When intersecting conditions A and B, you can return A 
if it implies B, or B if it implies A.

So I just wrote this (translated here to the PEP 3124 dialect):

@around(intersect)
def intersect_if_implies(c1:object, c2:object, nm:next_method):
     if implies(c1, c2):
         return c1
     elif implies(c2, c1):
         return c2
     return nm(c1, c2)

Because this method is @around, it is called before any ordinary 
methods are called, even if they apply to more specific types than 
'object'.  This means you only have to define intersection algorithms 
to handle conditions that don't imply each other.  (Assuming of 
course you've defined implies() relationships.)

When I realized I could do this, I was able to ditch a bunch of 
duplicated code in the individual intersect() relationships I had, 
and avoided having to write that code for the rest of the intersect() 
methods I had left to write.