Logged In: YES 
user_id=21627

This statement, as literally made, is incorrect:

>>> class X(Exception):
...   pass
...
>>> e=X()
>>> type(e)
<type 'instance'>
>>> raise e
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
__main__.X: <__main__.X instance at 0x401f2b4c>

In this example, type(e) works, and x is an object which has
Exception among its base classes. Still, I can throw x,
despite your claim that I cannot.

Even if I interpret your statement more literally (i.e. that
you are talking about objects for which type(e) is a
new-style class): Why do you think this statement explains
there is a bug?

As for why it is a new feature: it currently doesn't work,
and anybody trying it will quickly find out that it doesn't
work. The language reference says it doesn't work. The
TypeError you get says it doesn't work. So that it doesn't
work is clearly intentional; changing it will be a new feature.

Notice that it is very difficult to implement this feature,
as something needs to happen with strings and subtypes of
str. Currently, string exceptions are caught by identity. If
arbitrary objects can be used as exceptions, then strings
should also be caught by type, not by identity; this is a
backwards-incompatible change.

A clean solution would be to deprecate string exceptions in
2.5, completely ban them in 2.6, and allow arbitrary objects
to act as exceptions in 2.7. 

Please do read the entire thread of this RFE.