Hi, So if I understand all this correctly there are two things going on:
1) There's a bug with re-interpret which does not respect the unicode_literals from the original source. 2) re-interpret is being used instead of rewrite because an assert occurs in a file which is not a test module itself. The second here is basically the same as https://bitbucket.org/hpk42/pytest/issue/612/syntax-error-on-assertion-reinterpretation IIUC. To be perfectly honest my personal reaction to this is and has always been (before I was aware that this is a way to trigger re-interpret) that one should not have assertions in fixtures. Now experience seems to indicate I might be rather lonely in that opinion so maybe that's not a too useful stance. I've been trying to think about this a few times but haven't really found a useful answer to this problem yet. As for the former issue here: I'm not sure if anyone is going to have a lot of enthusiasm to fix this given that I think we would kind of like to drop re-interpret at some point. I suspect some features have been sneaking in which do not properly work in re-interpret by now and it's generally not been getting much love since rewrite came about. So I think it's much more important to try and find a solution for problem of re-write being avoided. But obviously a pull request with a fix would still be gratefully accepted. Regards, Floris On 25 November 2014 at 12:49, Bruno Oliveira <nicodde...@gmail.com> wrote: > Hi everyone, > > Besides the problem that reinterpret is executing code in a context without > unicode_literals enabled, this also showcases that when moving a fixture > with has asserts on it from a test file to a conftest file, asserts will not > be rewritten anymore and reinterpretation will be used instead, which might > cause unexpected issues, as illustrated by Gustavo. > > The first issue looks like a bug to me, not sure what to do about this > second point. Any thoughts? > > Cheers, > > On Mon, Nov 24, 2014 at 1:51 PM, Edison Gustavo Muenz > <edisongust...@gmail.com> wrote: >> >> TL;DR; >> >> The eval() method of the Frame object is not “inheriting” the __future__ >> imports from the frame. >> >> Long explanation >> >> Suppose I have a fixture in which I write my assert statements. If this >> fixture has strings on the assert statement then when the assert fails I get >> the wrong kind of errors. >> >> The problem is that the pytest assertion rewrite mechanism is calling >> eval() on the code that contains the frame >> >> To better illustrate what happens, see this gist >> >> The tests have the following output: >> >> test_plugin_fixture - fail >> test_conftest_fixture - fail >> test_inline_fixture - pass >> test_no_fixture - pass >> >> The output of test_plugin_fixture (omitted some output for brevity): >> >> $ pytest -k test_plugin_fixture >> >> msg = e.value.msg >> > assert msg.startswith('assert <classes.ValueAndString object'), >> > msg >> E AssertionError: ValueError: ValueAndString(2, 'lkajflaskjfalskf') >> << Error! >> >> While debugging I found out that the ValueAndString constructor was being >> called 3 times, instead of 2. The 3rd call happened in code.py:100, which is >> part of the py lib library. The “wrong” behaviour can be seen on the >> run_pyframe_eval.py. >> >> I’ve tested this code on Pytest 2.6.4 with Python 2.7.8 in Windows 7 - >> 64bits. >> >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev@python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > > > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev > _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
