[py-dev] Gitting rid of "(inconsistently failed then succeeded)" ?

[Philippe Fremy]

holger krekel wrote:
> Hi Philippe, Neil, 
> 
> On Fri, Apr 24, 2009 at 14:45 +0200, Philippe Fremy wrote:
>> Neil Shepperd wrote:
>>> Hi,
>>>
>>>> I have found that storing the results of the call I want to test the
>>>> result of, and then asserting the result generally eliminates these
>>>> errors.
>>>>
>>>> For example:
>>>>
>>>> assert Foo() == 23
>>>>
>>>> often caused me problems with that message, however:
>>>>
>>>> foo = Foo()
>>>> assert foo == 23
>>>>
>>>> would not.
>>>>
>>>> I am not sure why that is the case but I was able to resolve the issue
>>>> using the second form.
>>> If I understand it correctly, the test handling magic evaluates each
>>> part of the expression again, to display it in the fail traceback.
>>> For example, in the traceback of some test it will say:
>>>
>>>      def test_xxx():
>>> E        assert Foo() == 23
>>>>        assert 0 == 23
>>> If Foo() returns 0. It is run again get the value 0 to substitute into
>>> the error message. However if the second time it is run Foo() actually
>>> works correctly and returns 23, this value is obviously not correct,
>>> because if it were the assert would have passed.
>>>
>>> I suspect maybe py.test is evaluating t.isAlive() again to substitute
>>> into the if-expression, resulting in confusion when the result changes
>>> to True. If that is the case, you might have to do something like
>>>
>>>         checker.stop( False )
>>>         is_alive = t.isAlive()
>>>         is_finished = checker.isFinished()
>>>         if not is_alive: assert False
>>>         if is_finished: assert False
>>>
>>>
>>> Hope this made sense,
>> Thanks, it makes sense now on the cause of the error. This ought to be
>> documented somewhere in py.test
> 
> i agree, the error message is slightly mysterious. what about this: 
> 
>     def test_inconsistent():
>         def f(l=[1,0]):
>             return l.pop()
>>       assert f()
> E       AssertionError: (assert failed but re-evaluating the
> assert expression for printing intermediate values lead to a
> True value. advise: avoid side-effects in assert expressions
> or use --nomagic)

I like it :-)

As long as it's documented somewhere what's the cause and how to get
around it, I'm fine.

cheers,

Philippe