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 that interactive examples from > a test file or a test object work as expected. > To write tutorial documentation for a package, liberally illustrated with > input-output examples. Depending on whether the examples or the expository > text are emphasized, this has the flavor of “literate testing” or “executable > documentation”. https://docs.python.org/2/library/doctest.html (and this is not at all the purpose of the unittest module) If a function returns a set, and the normal way to use it is to call the function and get a set, then the example should be to call the function and get a set: >>> function() set([1, 2, 3]) Doctest should therefore be able to test that the example actually works and returns the correct set, regardless of how the set elements are displayed. It should not be required to add unusual extra code to format the output specifically so that doctest can understand it: >>> function() == set([1, 2, 3]) True (This is not a realistic example, because the user wouldn't know what the output is until they call the function.) >>> sorted(function()) [1, 2, 3] (This is not how the method is actually used in reality. It returns a set for a reason, not a list.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3332> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
