I also have to comment on the "makes the API simpler to use" note in the
checkin message. No, no it doesn't. See all those "warning[-1]" calls in
the current unit tests? They're all unhelpful, because if a warning
doesn't get raised, you're going to get an IndexError instead of an
Assertion error (i.e. exactly the problem complained about in the
original message in this thread).

Losing the attributes from the WarningRecorder means that you have to
check if you got a warning first before you can check if you got the
*right* warning. With the cached attributes, you can just check for the
right warning, and only worry about the *number* of warnings in cases
where that is likely to matter (usually because you expect multiple
warnings from one operation).

These are all *solvable* problems, but I don't think right before a
release candidate is the time to be fiddling with it - so let's revert
back to providing this feature only through the regression test suite
and deal with moving it into a more "official" part of the standard
library in a later release after this version has had a chance to bake
for a while (the twisted folks can always try to import it from our test
suite, and copy our implementation as a fallback if the test suite isn't
available for some reason).