Running with --pdb causes import failure

[r-owen]

I'm running py.test with --pdb and when something goes wrong I get an unwanted failure here:

from doctest import UnexpectedException

in _pytest/pdb.py which is done only executed after the problem has been detected. The problem is that the error that is triggering pdb is running out of file handles, and that apparently makes the import fail.

I suggest moving that import to near the top of the file, with other imports, so UnexpectedException is guaranteed to be available.

I suspect this will be hard to unit test, since you'll have to explicitly run out of file handles.

This is using Python 2.7 on OS X 10.11 with pytest 2.9.2

[mandeep]

I'd like to work on this as a way to get acclimated to the pytest code base. If the idea is to move the import to the top of the file, wouldn't something in test_capture.py need to be changed?

[RonnyPfannschmidt]

note that in pytest 3.x the module is _pytest/debugging.py

i think that move would be sufficient

[mandeep]

@RonnyPfannschmidt when moving the import in debugging.py to the top of the file, the python3 tests fail during test_logging_initialized_in_test in test_capture.py.

    def test_logging_initialized_in_test(self, testdir):
        p = testdir.makepyfile("""
            import sys
            def test_something():
                # pytest does not import logging
                assert 'logging' not in sys.modules
                import logging
                logging.basicConfig()
                logging.warn("hello432")
                assert 0
        """)
        result = testdir.runpytest_subprocess(
            p, "--traceconfig",
            "-p", "no:capturelog")
        assert result.ret != 0
        result.stdout.fnmatch_lines([
            "*hello432*",
        ])
        assert 'operation on closed file' not in result.stderr.str()

The full assertion error report can be found here: https://bpaste.net/show/d0e649b5c7bd

Looks like the test fails due to fnmatch not finding a match for hello432.

I'm not sure how the import and this test relate, any advice would be appreciated.

[RonnyPfannschmidt]

it seems that doctest imports logging, thus breaking the expectation of the test

[nicoddemus]

it seems that doctest imports logging, thus breaking the expectation of the test

So I guess moving from doctest import UnexpectedException to the top of the file is not really an option.

@r-owen if you are running out of file-handles, I'm guessing you will fail sometime soon anyway so just moving doctest to the top probably won't fix your problem.

[timj]

I think @r-owen's point is that pytest fails before it can report what the real error is because it can't load the correct exception. If the exception was pre-loaded then it would be able to report the actual error.

[timj]

One alternative would be to protect that import:

try:
    from doctest import UnexpectedException
except:
    UnexpectedException = RuntimeError

then at least we could properly throw something even if the type of the exception is wrong. I don't know if there is code higher up that is trying to catch UnexpectedException. Another way forward would be to put the UnexpectedException definition in a different place that can be loaded by this code and by doctest. Would that help the logging problem?

[r-owen]

@timj is correct: if the test fails due to running out of available open files the the reporting of the test must not try to open any more files, thus must not import any additional modules. Otherwise the reported error is confusing.