cjwatson
commented
3 years ago It's true that maybe_a_traceback is somewhat loose, though from its header comment it's not clear that it can be tightened up very much (in particular, it's not possible to check for the "Traceback" header because doctest preprocesses that away).
The ambiguity requires a bit more than your example as stated, though: maybe_a_traceback is only called (directly or indirectly) if the IGNORE_EXCEPTION_MODULE_IN_PYTHON2 option flag is set. So if this does become a problem in a given doctest file, then it can be fixed by only setting that option flag on examples that are expected to raise exceptions, just as you wouldn't set IGNORE_EXCEPTION_DETAIL on everything.
That said, at least zope.app.publisher and zope.app.testing fail with this, because they have tests that look like this in files where IGNORE_EXCEPTION_MODULE_IN_PYTHON2 is enabled globally:
>>> print(http(wsgi_app, r"""
... POST /@@contents.html HTTP/1.1
... Authorization: Basic bWdyOm1ncnB3
... Content-Length: 73
... Content-Type: application/x-www-form-urlencoded
...
... type_name=BrowserAdd__zope.site.folder.Folder&new_value=f1"""))
HTTP/1.1 303 See Other
...So is the right thing to do: (a) to update these packages to set this option flag more selectively and bump zope.testing's major version number; (b) something more clever I haven't thought of; (c) drop the idea entirely?
mgedmin
When porting code from Python 2, it's sometimes necessary to handle doctests with expected output like this:
This happens when raising an exception with no arguments; there are a few cases like this in Launchpad. We can support this by making
maybe_a_tracebackslightly more liberal.