Doctest capture only AssertionError but not printed text

[osantana]

BPO	21183
Nosy	@tim-one, @stevendaprano, @osantana
Files	doctest_bug.py: Example that reproduces error

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2014-04-09.02:13:50.991>
labels = ['type-feature', 'library']
title = 'Doctest capture only AssertionError but not printed text'
updated_at = <Date 2014-04-09.03:18:12.649>
user = 'https://github.com/osantana'

bugs.python.org fields:

activity = <Date 2014-04-09.03:18:12.649>
actor = 'steven.daprano'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2014-04-09.02:13:50.991>
creator = 'osantana'
dependencies = []
files = ['34771']
hgrepos = []
issue_num = 21183
keywords = []
message_count = 5.0
messages = ['215796', '215797', '215798', '215799', '215800']
nosy_count = 3.0
nosy_names = ['tim.peters', 'steven.daprano', 'osantana']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21183'
versions = ['Python 3.5']

[osantana]

The following doctest should pass, but it fails:

    >>> def spam(): print("eggs")
    ...
    >>> assert spam()
    eggs
    Traceback (most recent call last):
    AssertionError

But if we remove the print output from printed results the test pass:

    >>> def spam(): print("eggs")
    ...
    >>> assert spam()
    Traceback (most recent call last):
    AssertionError

I'm writing the 2nd edition of a book about Python (covering python3) and Django and I'm using doctest to run the interactive sessions that I use as examples in book.

[tim-one]

The first footnote in the docs explain this:

Examples containing both expected output and an
exception are not supported. Trying to guess where
one ends and the other begins is too error-prone,
and that also makes for a confusing test.

So, sorry, but this is intentionally not supported.

[osantana]

Hi Tim,

I tried to find more information in documentation before opening this bug but I need to confess that I didn't read the footnote.

Thanks and sorry for the invalid report.

[stevendaprano]

Personally, I think that the second reason given in the footnote, that it makes for confusing tests, is bogus, or at least it's a matter of opinion. I for one don't think they are confusing, and would like to see mixed output/tracebacks supported. Tim, would you accept this being reopened as an Enhancement request for 3.5 rather than a bug fix?

[tim-one]

Steven, no objection here.