[MAL]
> Since exception message are not defined anywhere I'd suggest
> to simply ignore them in the output.
[Tim]
> Virtually nothing about Python's output is clearly defined, and for doc
> purposes I want to capture what Python actually does.
[MAL]
> But what it does write to the console changes with every
> release (e.g. just take the repr() changes for strings with
> non-ASCII data)...
So now you don't want to test exception messages *or* non-exceptional output
either. That's fine, but you're never going to like doctest if so.
> this simply breaks you test suite every time
I think you're missing the point: it breaks your *docs*, if they contain
any examples that rely on such stuff. doctest then very helpfully points
out that your docs-- no matter how good they were before --now suck, because
they're now *wrong*. It's not interested in assigning blame for that, it's
enough to point out that they're now broken (else they'll never get fixed!).
> Writing Python programs which work on Python 1.5-2.1 which at
> the same time pass the doctest unit tests becomes impossible.
Not true. You may need to rewrite your examples, though, so that your
*docs* are accurate under all the releases you care about. I don't care if
that drives you mad, so long as it prevents you from screwing your users
with inaccurate docs.
> The regression suite (and most other Python software) catches
> exceptions based on the exception class -- why isn't this enough
> for your doctest.py checks ?
Because doctest is primarily interested in ensuring that non-exceptional
cases continue to work exactly as advertised. Checking that, e.g.,
>>> fac(5)
120
still works is at least 10x easier to live with than writing crap like
if fac(5) != 120:
raise TestFailed("Something about fac failed but it's too "
"painful to build up some string here "
"explaining exactly what -- try single-"
"stepping through the test by hand until "
"this raise triggers.")
That's regrtest.py-style testing, and if you think that's pleasant to work
with you must never have seen a std test break <0.7 wink>.
When a doctest'ed module breaks, the doctest output pinpoints the failure
precisely, without any work on your part beyond simply capturing an
interactive session that shows the results you expected.
> nit-pickling-ly,
Na, you're trying to force doctest into a mold it was designed to get as far
away from as possible. Use it for its intended purpose, then gripe. Right
now you're complaining that the elephant's eyes are the wrong color while
missing that it's actually a leopard <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4