endolith added the comment:
The fundamental purpose of doctest is to test that examples in documentation
work correctly:
To check that a module’s docstrings are up-to-date by verifying that all
interactive examples still work as documented.
To perform regression testing by verifying
Tim Peters added the comment:
This should remain closed. It's a feature that doctest demands exact textual
equality, and that the only way to override this is with one of the `#doctest:`
flags. What you see is what you get - exactly is one of doctest's
fundamental design goals.
If you
endolith added the comment:
I ran into this bug with sets, too.
Expected:
{6, 5, 3}
Got:
set([5, 3, 6])
Documentation should illustrate how the function is actually meant to be used,
not contrived examples that convert to sorted output purely so that doctest can
understand them.
Raymond Hettinger added the comment:
doctest should be changed (or have an option) to understand
object equality rather than exact text output.
Sorry, but that would be at odds with the fundamental design of doctest which
is principally designed to test documentation in the form of
New submission from Jens Diemer [EMAIL PROTECTED]:
The doctest doesn't work good, if a function returns a dict.
Here a simple example:
def test(d):
This works:
test({A:1, B:2, C:3})
{'A': 1, 'C': 3, 'B': 2}
This failed, because of different dict sort:
test({A:1,
Tarek Ziadé [EMAIL PROTECTED] added the comment:
This is not a bug: dict do not guarantee the ordering of the keys, so it
may change on every run.
A good practice is to test a sorted .items() output of your dict in your
doctest.
--
nosy: +tarek
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Closing as not a bug.
FWIW, here's the relevant text from the docs:
-
23.2.3.6 Warnings
doctest is serious about requiring exact matches in expected output. If
even a single character doesn't
