Here is the reason. Starting from Python 2.6, classes can redefine
subclass checking using a special method named __subclasscheck__. Since
this method can contain arbitrary code, we have to guard against
recursion when calling it. Therefore, the recursion count is incremented
before doing a subclass checking.

Now the problem is that when checking for an exception, we do exactly
that: check whether the raised exception is a subclass of a given type.
If the raised exception occurred just after a recursion overflow, it can
happen that subclass checking overflows the recursion count again.
However, since we don't want the newly raised exception (during
exception subclass checking) to overwrite the original one, so we just
write out it (using PyErr_WriteUnraisable, precisely) and then discard it.

That's where these strange messages come from.
(note: py3k has a slightly different recursion checking mechanism and
doesn't print such messages)