[issue19746] No introspective way to detect ModuleImportFailure in unittest

Peter added the comment: This comment is just to note that this change broke our (exotic?) usage of unittest.TestLoader().loadTestsFromName(name) inside a try/except since under Python 3.5 some expected exceptions are no longer raised. My nasty workaround hack: https://github.com/biopython/bio

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Roundup Robot added the comment: New changeset e906e23931fa by Robert Collins in branch 'default': Close #19746: expose unittest discovery errors on TestLoader.errors https://hg.python.org/cpython/rev/e906e23931fa -- nosy: +python-dev resolution: -> fixed stage: -> resolved status: ope

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Robert Collins added the comment: Right: the existing code stringifies the original exception and creates an exception object and a closure def test_thing(self): raise exception_obj but that has the stringified original exception. -- ___ Python

[issue19746] No introspective way to detect ModuleImportFailure in unittest

R. David Murray added the comment: Oh, ok, if the existing glue does it that way, then it seems fine. I thought when I read the code that it was holding a reference to the traceback until it raised the error in the synthetic test. Or do you mean that when exceptions are raised by tests it is

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Robert Collins added the comment: I can certainly write the reporter glue to work with either a string or a full reference. Note that the existing late-reporting glue captures the import error into a string, and then raises an exception containing that string - so what I've done is consistent

[issue19746] No introspective way to detect ModuleImportFailure in unittest

R. David Murray added the comment: Yeah, I figured out it was loader only errors after I read the code :) "load_tests not called" is very different from "load_tests produced an exception", so the text of the error message should be changed accordingly. I understood your use case more-or-less,

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Robert Collins added the comment: Thanks; I'm still learning how to get the system here to jump appropriately :). I thought I'd told hg to reset me to trunk... "You are right about the docs. Reading that, I thought it was saying that errors would have a list of the errors that show up in the

[issue19746] No introspective way to detect ModuleImportFailure in unittest

R. David Murray added the comment: Your patch isn't diffed against a revision from the cpython repo, and apparently didn't apply cleanly to tip, so no review link was generated. I uploaded a rebased patch to review, but don't actually have any line by line comments. You are right about the

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Changes by R. David Murray : Added file: http://bugs.python.org/file36587/issue19746-rebased.patch ___ Python tracker ___ ___ Python-bugs-list

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Robert Collins added the comment: Here is an implementation. I'm probably missing some finesse in the docs. -- keywords: +patch Added file: http://bugs.python.org/file36577/issue19746.patch ___ Python tracker _

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue19746] No introspective way to detect ModuleImportFailure in unittest

Changes by Nick Coghlan : -- title: No introspective way to detect ModuleImportFailure -> No introspective way to detect ModuleImportFailure in unittest ___ Python tracker ___ _