[PEAK] Patch to clear RuleSet

[Phillip J. Eby]

At 10:25 PM 7/15/2008 +0200, Alberto Valverde wrote:
>Phillip J. Eby wrote:
> > At 11:05 AM 7/15/2008 -0400, Phillip J. Eby wrote:
> > (....)
> > Okay, both RuleSet.clear() and a fixed RuleSet.__iter__ are in SVN and
> > a snapshot build now, along with a temporary fix for the IsSubclass
> > issue.
> >
> > It seems to me that there is more to the issubclass issue than meets
> > the eye, in that there are potentially other test combinations that
> > might really need to be ordered similarly.  I'll write up another post
> > with some thoughts on that as soon as it's practical.
>
>Thanks for the quick "temporary" fix :) I've  just uncommented some
>tests I had which depended on isclass acting as a guard and they all pass.

It wasn't "isclass" that was broken; it was that issubclass() was 
allowed to go first -- didn't matter what the other criteria were.

The bigger issue is what types of tests should be allowed to go 
first.  Currently, anything but issubclass() that's a test on a plain 
argument is allowed to run in any order, but I can think of error 
scenarios for everything except "is", especially if you consider that 
one argument's contents might dictate the contents of another.

The flip side is to just require tests to always occur in the order 
of appearance; this is more predictable and "safer", but could carry 
a performance cost if the order used in the rules as written 
conflicts with the optimum order from a selectivity point of view.

I could make the order analysis smarter, in order to detect whether a 
given criterion should "count" for enabling another criterion, but 
the downside is that it turns what's now a O(n) operation into an 
O(n**2) operation.

So, for now, I've just disabled re-ordering of issubclass() criteria.