R. David Murray <rdmur...@bitdance.com> added the comment: The problem is that it would be equally reasonable for someone to want to put real tab characters in the output section (which results in strange looking doctest text) or to put expanded spaces in the doctest output section based on the assumption that output starts in the column under the first > of the >>> and that doctest will expand the tabs in the output it receives from the executed test using a tabstop of 8. Neither of these is a good solution (the first gives you messed up looking doctests, the second means the output you document isn't really the output the test gives). The second solution would also mean a significant rewrite of the doctest processing loop. So the best course, since doctests are *primarily* about documentation, is to allow tabs in the output only with whitespace normalization. (If you really want to test for the presence of tabs in the output, as opposed to just creating documentation, you can capture the output and test it using string comparis on.)
Personally I think the 'too bad' language in the docs is not really appropriate, so if you can think of a succinct way to document the above, I'll see about getting it in to the docs. ---------- components: +Documentation -Library (Lib) stage: patch review -> needs patch title: doctest should normalize tabs when comparing output -> Improve explanation of tab expansion in doctests type: behavior -> feature request _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7583> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
