The doctest module does not compare multiline strings properly, as attached example proves. 

Tested on 2.7, 3.6 and 3.9.0a5+. (platform: Ubuntu 18.04).

Related: https://stackoverflow.com/questions/60956015/unexpected-errors-while-testing-python3-code-with-doctest

Did you try to run the tested function in the interactive Python interpreter? Did you get what you expected?

@Serhiy, Thank you for feedback. 

Yes the "testme" function (indeed trivial) works as expected - both in interactive Python interpreter and in script file. 

If you go to Lib/doctest.py, search for "string-identical" and debug my example there, you will see the problem is real.

I don't see an easy fix for the problem, I only suspect it's related to io.StringIO getvalue() method.

Actually, the behavior does not depend on leading spaces, and test case can be isolated even further. Sample is attached [doctest-bugs-2.py].

Have you tried calling multiline_output() in the REPL?

It does *not* show your expected output:

    # expected
    First line
    Second line


but the string repr():

    # actual
    'First line\nSecond line\n'



Change your doctest to either:


    >>> multiline_output()
    'First line\\nSecond line\\n'

(note that you must escape the backslashes) or:

    >>> print(multiline_output())
    First line
    Second line
    <BLANKLINE>


Note that the "<BLANKLINE>" needs to be written literally, as described here:

https://docs.python.org/3/library/doctest.html#doctest.DONT_ACCEPT_BLANKLINE

By the way Filip, you were told on the Stackoverflow page that the output was correct and that you were not using doctest correctly. Serhiy also hinted to you that you should check the output in the REPL and you falsely claimed that it gave the expected output, but it doesn't:

    py> multiline_output()
    'First line\nSecond line\n'

which is nothing like the output you put in your doctest.

This is not a bug in doctest. The very first line of the doctest documentation says:

    The doctest module searches for pieces of text that look like
    interactive Python sessions

so this is expected and documented behaviour, not a bug.