[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
Hi,
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
sense?)
Alberto
P.S Thanks for the recent efforts in documenting peak.rule's internals!
More information about the PEAK
mailing list