Re: Patch to clear RuleSet
"Phillip J. Eby" <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]>
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <[email protected]> |
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.