[PEAK] Use cases for the priority feature

[Christoph Zwerschke]

Am 18.08.2010 01:14 schrieb P.J. Eby:
 > The new API is to import things from the main peak.rules module if
 > it's to "use" peak.rules. If it's to "extend" peak.rules, you import
 > from the defining module.

Makes sense.

 > @expand_as lets you turn functions into conditions, e.g.:
 >
 > @expand_as("filter is None or value==filter")
 > def check_condition(filter, value):
 >     pass
 >
 > You can then use "check_condition(x, y)" in a rule somewhere, and
 > it'll be treated as if you'd said "x is None or x==y" in the rule
 > directly.
 >
 > And 'let()' is a pseudo-function you can use in a rule to create
 > temporary "variables" to simplify complex conditions. You can then
 > also have those variables passed in to extra arguments on your
 > rule's method... a bit like pattern matching in other languages.

Nice. That allows some abbreviation.

 >> You should document the "value" function somewhere, it's simple but
 >> handy, but at first I didn't see where it was coming from.
 >
 > Um, it's in README.txt, line 278. (The section just before
 > "combine_using". It's got examples and everything. ;-)

Ah, I was only looking at the online docs. It's still missing there.

 >> But isn't the problem here that every function gets evaluated, and
 >> only then the maximum is calculated?
 >
 > Only the *applicable* ones.

Yes, of course. But they might still be many.

 > Hm. I just thought of a totally different way to do priorities in
 > that case:
 >
 > when("requestedQuality>20 and ...")
 >
 > Then always request the maximum quality -- higher levels will imply
 > lower ones, and thus be more specific. ;- ) (i.e. if quality>20, then
 > it also is >10.)

Hey, yes, that's a much better solution! Just making use of the rules 
for range objects.

 > You do have to have unique quality levels in that case, but then, you
 > also have to have unique priorities in that case.

Right, you have to add sublevels to achieve that anyway.

 > I am worried, though, that numeric priorities built into the system
 > encourages people to impatiently wave their problems away without
 > learning anything... until their rules are so encumbered by magical
 > priority numbers that they end up spending so much time tweaking the
 > priorities that they decide to do without rules altogether. ;-)

That fear is certainly not unfounded, but I think the only remedy for 
that is adding more "for dummies" docs and examples like the ones we're 
discussing right now. The docs so far explained everything, but they 
were too dry and theoretical for the rest of us.

If Python's only documentation was the Language Reference, I guess few 
people would be using it ;-)

-- Christoph