[Python-3000] pep 3124 plans

[Terry Reedy]

"Phillip J. Eby" <pje at telecommunity.com> wrote in message 
news:20070719160724.62AE73A403A at sparrow.telecommunity.com...
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.

=====================================
As a side note: if you have either a negate() or disjoint(), you can also 
handle a 3rd of the 4 cases object-generically:
   elif disjoint(c1,c2): return <empty> #or
   elif implies(c1, negate(c2): return <empty> # symmetrical with
   elif implies(c2, negate(c1): trturn <empty>

and then the intersection algorithms can assume non-disjointness.

tjr