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:
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: open
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
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
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
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, my
Changes by R. David Murray rdmur...@bitdance.com:
Added file: http://bugs.python.org/file36587/issue19746-rebased.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19746
___
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
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
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 rep...@bugs.python.org
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19746
___
___
Python-bugs-list
Michael Foord added the comment:
Seems like a perfectly reasonable request. I've no particular preference on an
api for this though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19746
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: No introspective way to detect ModuleImportFailure - No introspective
way to detect ModuleImportFailure in unittest
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19746
New submission from Robert Collins:
https://bugs.launchpad.net/testtools/+bug/1245672 was filed on testtools
recently. It would be easier to fix that if there was some way that something
loading a test suite could check to see if there were import errors. The
current code nicely works in the
14 matches
Mail list logo
