Jean-Paul Calderone wrote:
The first assertion passes (by the way, I don't understand why w.message
isn't the message passed to warn, but is instead an instance of
UserWarning)
but the second assertion fails.
See Brett's comment elsewhere in this thread about the level of thought
(or lack thereof) that went into the design of some of the test_support
APIs (including catch_warning).
A more subtle example might include two
functions, the first of which is deprecated and called by the second, and
one test for each of them. Now the test for the warning will only pass if
it runs before the other test; if they accidentally run in the other order,
you won't see the warning, so as far as I can tell, you can't reliably
write
a unit test for warnings using catch_warning.
Yeah, the Python regression tests actually cheat quite a bit when it
comes to testing warnings - several of the tests clear the warning cache
just in case the warning has already been triggered by other code.
I suspect what some of those tests *should* be doing (aside from those
testing the warning module itself) is configuring the warning system to
convert the relevant warnings to exceptions, then catching the resulting
exception.
The real problem with testing many uses of the warning system is that it
doesn't expose enough public APIs for this to be possible. You *have*
to use APIs which are, apparently, private (such as warn_explicit).
Hmm, I think the bigger problem is that there is no documented way to
save the warnings filter and restore it to a previous state - the
'filters' attribute (which holds the actual list of filters) isn't
documented and isn't included in __all__. This makes it hard to write an
officially supported test that fiddles with the warning settings then
puts them back the way they were.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
