[Python-3000] pep 3124 plans (original) (raw)

Terry Reedy tjreedy at udel.edu
Thu Jul 19 19:15:30 CEST 2007

"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 #or elif implies(c1, negate(c2): return # symmetrical with elif implies(c2, negate(c1): trturn

and then the intersection algorithms can assume non-disjointness.

tjr

More information about the Python-3000 mailing list