[PEAK] issues while porting priority_methods to use peak.rules.predicates.priority

Alberto Valverde alberto at toscat.net
Tue Aug 17 17:21:55 EDT 2010


Recent changes in PEAK-Rules have broken prioritized_methods. 
Fortunately in a good way, it is no longer necessary :)

In order not to break clients (eg: turbojson and rum) and give them some 
time to upgrade their rules using the mechanisms provided by peak.rules, 
I'd like to re-implement it as a thin compatibility layer using the new 
"priority" criterion in peak.rules.

However, I've found a slight semantic difference which I'm not sure how 
to emulate, the following test (adapted from one inside 
prioritized_methods' test suite) illustrates it:

class TestPriority(unittest.TestCase):
     def test_more_specific_sig_overrides(self):
         from peak.rules.predicates import priority
         def f(n, m):
             return n
         when(f, "n==5")(lambda n, m: n+5) #f1
         when(f, "n==5 and priority(1)")(lambda n, m: n+10) #f2
         when(f, "n==5 and m==5")(lambda n, m: n+25) #f3
         self.failUnlessEqual(f(5,1), 15)
         self.failUnlessEqual(f(5,5), 25) # raises AmbiguousMethods 
between f2 and f3

Is there any way to tell peak.rules to consider that a "priority" is 
always implied by any other criterion so the fact that it is present in 
a predicate doesn't raise the predicate's selectiveness? (does that make 


P.S Thanks for the recent efforts in documenting peak.rule's internals!

More information about the PEAK mailing list