[Python-3000] pep 3124 plans
Phillip J. Eby
pje at telecommunity.com
Thu Jul 19 17:56:17 CEST 2007
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
>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):
def intersect_if_implies(c1:object, c2:object, nm:next_method):
if implies(c1, c2):
elif implies(c2, c1):
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.
More information about the Python-3000