<div dir="ltr">True about the bugnumbers.  Not always diferent bug numbers, but certainly sometimes.  <div><br></div><div>The reason I don't like writing them as separate decorators is because we have tons of cases where the condition of multiple decorators pass, and the best we can do is report one bugnumber / reason in the output because we don't even evaluate the rest after that.  If the entire conditional is specified on one decorator, you can support that.</div><div><br></div><div>With functional style you could still support multiple bugnumbers on an or conditional like this:<div><br></div><div>@xfail(or(compiler("gcc", [">=", 4.7], bugnumber=12345), hostos("windows", bugnumber=23456)))</div><div><br></div><div>which is equivalent to:</div><div>@xfail(compiler="gcc", compiler_version=[">=", 4.7], bugnumber=12345)</div><div>@xfail(hostoslist="windows", bugnumber=23456)</div><div><br></div><div><span style="line-height:1.5">I think also having many layers of decorator nesting provides an implementation challenge.  Ultimately we would like to re-use the skipif functionality of unittest / unittest2 (especially since we want to port to unittest).  So it would be nice if we could write our decorator like this:</span><br></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">def skipIf(...):</span></div><div><span style="line-height:1.5">    def fn(...):</span></div><div><span style="line-height:1.5">        ...</span></div><div><span style="line-height:1.5">    unittest2.skipIf(fn)</span></div><div><br></div><div>Right now we can't do this because the nature of the nested decorators requires us to hack together our own implementation of skipif so that we can manually call into the next decorator under the right conditions.  If we have just one decorator, it's much easier to write it in terms of unittest.skipIf.  Just construct the function that evaluates the condition, and pass it in to unittest.  </div><div><br></div></div><div>(For what it's worth, I'm not planning to do any of this extra stuff right now, or even soon, so this is all theoretical at this point.  Right now I just want to remove low hanging fruit and reduce the number of decorators, but not get it down all the way to 2).</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 9, 2016 at 10:29 AM Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9 February 2016 at 17:51, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> I agree that you don't need arbitrary complexity, but I think there are some things we would greatly benefit from.  For example, have you ever seen this?<br>
><br>
>   @expectedFailureWindows<br>
>   @expectedFailureGcc<br>
>   @expectedFailureHostLinux<br>
><br>
> That's 3 decorators, when you could write it as 1:<br>
><br>
>   @expectedFailure(or(oslist="windows", compiler="gcc", hostoslist="linux"))<br>
<br>
Maybe that's a matter of preference, but I would much rather see the<br>
former than the latter.<br>
<br>
What I would like to avoid is having two decorators like:<br>
@xfail(or(a=A, not(b=B)), c=C')<br>
@xfail(a=A', or(b=B', not(c=C')))<br>
on a single test. At that point it becomes quite impossible to figure<br>
out when the test gets run.<br>
<br>
Also, arguably, if you are doing "or", then you are probably dealing<br>
with separate bugs, and each should deserve it's own bugnumber.<br>
<br>
pl<br>
</blockquote></div>