Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running with --pdb causes import failure #1810

Closed
r-owen opened this Issue Aug 16, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@r-owen
Copy link

r-owen commented Aug 16, 2016

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

This comment has been minimized.

Copy link
Contributor

mandeep commented Sep 22, 2016

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

This comment has been minimized.

Copy link
Member

RonnyPfannschmidt commented Sep 22, 2016

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

i think that move would be sufficient

@mandeep

This comment has been minimized.

Copy link
Contributor

mandeep commented Sep 22, 2016

@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

This comment has been minimized.

Copy link
Member

RonnyPfannschmidt commented Sep 22, 2016

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

@nicoddemus

This comment has been minimized.

Copy link
Member

nicoddemus commented Sep 22, 2016

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

This comment has been minimized.

Copy link

timj commented Sep 22, 2016

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

This comment has been minimized.

Copy link

timj commented Sep 22, 2016

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

This comment has been minimized.

Copy link
Author

r-owen commented Sep 22, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.