classification
Title: test_syntax_error fails when run in the installed location
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.3, Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: doko, ezio.melotti, georg.brandl, michael.foord, pitti, python-dev, rbcollins, terry.reedy
Priority: normal Keywords:

Created on 2013-04-16 11:32 by doko, last changed 2016-01-01 05:47 by ezio.melotti. This issue is now closed.

Messages (11)
msg187073 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-04-16 11:32
no idea yet about that one ...

======================================================================
FAIL: test_syntax_error (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_code_module.py", line 57, in test_syntax_error
    raise AssertionError("No syntax error from console")
AssertionError: No syntax error from console
msg199788 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-10-13 20:13
Can't reproduce with current 3.3 tip.
msg217917 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-05-05 11:58
seen this again in our autopkg tester
https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python3.4/12/

however now I can't reproduce this locally, and the test succeeds during the build.
msg217924 - (view) Author: Martin Pitt (pitti) Date: 2014-05-05 13:50
I can reproduce this here. In that test, I added the following:

        with open('/tmp/debug', 'w') as f:
            for call in self.stderr.method_calls:
                f.write('call: %s\n' % str(call))

 
This gives:
=========== 8< ============
call: call.write('Python <MagicMock name=\'sys.version\' id=\'140431558254320\'> on <MagicMock name=\'sys.platform\' id=\'140431558262512\'>\nType "help", "copyright", "credits" or "license" for more information.\n(InteractiveConsole)\n')
call: call.write('Traceback (most recent call last):\n')
call: call.write('  File "/usr/lib/python3.4/code.py", line 90, in runcode\n')
call: call.write('    ')
call: call.write('exec(code, self.locals)')
call: call.write('\n')
call: call.write('  File "<console>", line 1, in <module>\n')
call: call.write('NameError')
call: call.write(': ')
call: call.write("name 'undefined' is not defined")
call: call.write('\n')
call: call.write('\n')
=========== 8< ============

Observe that the test checks

            if 'NameError:' in ''.join(call[1]):

but the "NameError" and the ":" are in two different call lines. I don't know how self.stderr.method_calls is built, but this sounds like a race condition/timing or a stdin/out buffering issue? I. e. the original print that produces the "NameError:" certainly does that in two steps; perhaps the testsuite thing that repeatedly read()s on stderr catches these two as separate write()s then?
msg218086 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-05-07 22:05
adding unittest developers
msg218319 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2014-05-12 12:11
It looks like the simplest fix would be to change "NameError:" to "NameError", as the problem is that they're (sometimes!?) on separate lines.

This still tests what we want to test.
msg218320 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-05-12 12:17
sure, doing this. my follow-up question was if it is necessary to fix anything else in unittest.
msg218422 - (view) Author: Roundup Robot (python-dev) Date: 2014-05-13 09:30
New changeset 20db5e9086d4 by doko in branch '3.4':
- Issue #17756: Fix test_code test when run from the installed location.
http://hg.python.org/cpython/rev/20db5e9086d4

New changeset 8885fc2e92b3 by doko in branch 'default':
Merge from 3.4:
http://hg.python.org/cpython/rev/8885fc2e92b3
msg218423 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-05-13 09:32
not yet closing, to see if there are some stream buffering issues in mock
msg251026 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-09-18 21:00
In the absence of any further issue in over a year, can this be closed?
msg257278 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2016-01-01 05:47
I'm going to close this since the reported issue has been fixed.

In the test sys.stderr was mocked, and Mock.method_calls simply records the calls done to the mock.  Therefore the fact that 'NameError' and ':' were written on sys.stderr on two separate calls to write() is not a problem with mocks.
History
Date User Action Args
2016-01-01 05:47:35ezio.melottisetstatus: open -> closed

type: behavior

nosy: + rbcollins
messages: + msg257278
resolution: out of date -> fixed
stage: needs patch -> resolved
2015-09-18 21:00:25terry.reedysetnosy: + terry.reedy
messages: + msg251026
2014-05-13 09:32:39dokosetmessages: + msg218423
2014-05-13 09:30:45python-devsetnosy: + python-dev
messages: + msg218422
2014-05-12 12:17:57dokosetmessages: + msg218320
2014-05-12 12:11:27michael.foordsetmessages: + msg218319
2014-05-07 22:05:02dokosetnosy: + ezio.melotti, michael.foord
messages: + msg218086
2014-05-05 13:50:45pittisetnosy: + pitti
messages: + msg217924
2014-05-05 11:58:54dokosetstatus: pending -> open

messages: + msg217917
2013-10-13 20:13:48georg.brandlsetstatus: open -> pending

nosy: + georg.brandl
messages: + msg199788

resolution: out of date
2013-04-16 11:32:57dokolinkissue17750 dependencies
2013-04-16 11:32:39dokocreate