This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: test failure introduced by the fix for issue #22462
Type: behavior Stage: resolved
Components: Library (Lib), Tests Versions: Python 3.4, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: doko, eric.araujo, jkloth, pitrou, python-dev
Priority: normal Keywords:

Created on 2014-11-18 12:03 by doko, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (10)
msg231312 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-11-18 12:03
the fix for issue #22462 introduces a regression in the test_pyexpat test cases. I'm not yet sure why. This is only seen when running the testsuite from the installed location, which shouldn't matter.  Tried to run the tests with a stripped executable in the build tree worked too, so I'm lost why this now fails.  Confirmed that reverting the fix resolves running the testcase in the same environment.
msg231317 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-18 13:25
Please post the traceback.
msg231320 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-11-18 13:44
[258/383] test_pyexpat
test test_pyexpat failed -- Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 432, in test_exception
    parser.Parse(b"<a><b><c/></b></a>", 1)
  File "../Modules/pyexpat.c", line 405, in StartElement
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 422, in StartElementHandler
    raise RuntimeError(name)
RuntimeError: a

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 447, in test_exception
    self.assertIn('call_with_frame("StartElement"', entries[1][3])
  File "/usr/lib/python3.4/unittest/case.py", line 1053, in assertIn
    if member not in container:
TypeError: argument of type 'NoneType' is not iterable


test_exception (test.test_pyexpat.HandlerExceptionTest) ... ERROR

======================================================================
ERROR: test_exception (test.test_pyexpat.HandlerExceptionTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 432, in test_exception
    parser.Parse(b"<a><b><c/></b></a>", 1)
  File "../Modules/pyexpat.c", line 405, in StartElement
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 422, in StartElementHandler
    raise RuntimeError(name)
RuntimeError: a

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 447, in test_exception
    self.assertIn('call_with_frame("StartElement"', entries[1][3])
  File "/usr/lib/python3.4/unittest/case.py", line 1053, in assertIn
    if member not in container:
TypeError: argument of type 'NoneType' is not iterable

----------------------------------------------------------------------
Ran 36 tests in 0.016s
msg231322 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-18 13:52
Thanks. So, this is not a regression: the failing test was introduced in #22462 and probably would have not worked before, either. The problem is that "../Modules/pyexpat.c" makes sense from the checkout directory but not necessarily from the install location. I don't know if we should try to be smarter or not.

At first we could make the test more lenient.
msg231436 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-11-20 14:32
do we have something like skipIfInstalled?
msg231445 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-20 17:44
> do we have something like skipIfInstalled?

No. There's no exact way of checking for an installed Python, but one possibility is to test whether a given directory exists (e.g. "Modules").
msg231548 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2014-11-23 06:57
What about using “not sysconfig.is_python_build()”?
msg231561 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-23 14:57
> What about using “not sysconfig.is_python_build()”?

I had forgotten about it, thank you.
msg231862 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-11-29 14:56
New changeset e4b986350feb by Antoine Pitrou in branch '3.4':
Close issue #22895: fix test failure introduced by the fix for issue #22462.
https://hg.python.org/cpython/rev/e4b986350feb

New changeset 4990157343c6 by Antoine Pitrou in branch 'default':
Close issue #22895: fix test failure introduced by the fix for issue #22462.
https://hg.python.org/cpython/rev/4990157343c6
msg231864 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-29 14:57
This should be fixed now.
History
Date User Action Args
2022-04-11 14:58:10adminsetgithub: 67084
2014-11-29 14:57:17pitrousetstatus: open -> closed
resolution: fixed
messages: + msg231864

stage: resolved
2014-11-29 14:56:49python-devsetnosy: + python-dev
messages: + msg231862
2014-11-23 14:57:59pitrousetmessages: + msg231561
2014-11-23 06:57:42eric.araujosetnosy: + eric.araujo
messages: + msg231548
2014-11-20 17:44:00pitrousetmessages: + msg231445
2014-11-20 14:32:46dokosetmessages: + msg231436
2014-11-18 17:11:10dokolinkissue17750 dependencies
2014-11-18 13:52:49pitrousetpriority: high -> normal
title: regression introduced by the fix for issue #22462 -> test failure introduced by the fix for issue #22462
messages: + msg231322

components: + Tests
type: behavior
2014-11-18 13:44:03dokosetmessages: + msg231320
2014-11-18 13:25:20pitrousetmessages: + msg231317
2014-11-18 13:14:04jklothsetnosy: + jkloth
2014-11-18 12:03:32dokocreate