If you execute the following code::

try:
    raise Exception('a string')
except Exception, err:
    print type(err)

it prints out that ``err`` is a type 'instance'.  It would be nice if it returned the type of the actual argument (in this case, type 'str').

Logged In: YES 
user_id=31435

I'm a bit baffled by this, Brett:  when you instantiate a class, 
you can pass any number of arguments to its constructor.  
You happened to pass a single string argument when building 
an instance of Exception here, but you could have passed 
any number of arguments.  Why should the first argument be 
special?  (Or maybe you think the last argument should be 
special <wink>).  Or what if you didn't pass any arguments at 
all?

Having "the detail" bound to the instance object raised is a 
feature, and a major one.

If you're in the habit of passing a single string to Exception 
directly, note that you can already get it back via doing

    str(err)

in the "except" clause.

Logged In: YES 
user_id=357491

I must be misunderstanding how exceptions handle passed-in values at instantiation.  I know you can pass in multiple values (I assume it's ``def __init__(*args, **kwargs)`` for Exception), but I was not expecting an instance type.  I think I was expecting the values from ``.args`` to be unpacked and stored in the variables instead of an actual exception object to returned in there with a smart ``__str__`` method.  Perhaps the docs should clarify that you receive actual copies of the exception object with its ``args`` attribute set to the argument?  The tutorial, as-is, says "the except clause may specify a variable after the exception name (or list) to receive the argument's value" which suggests to me that I will get the physical argument I passed into the exception; I expected tuple unpacking of the ``args`` attribute.

In other words I see why it is the way it is, but perhaps we should clarify in the tutorial that it is an exception instance storing the arguments and not the arguments themselves?

And I actually used ``str(err)`` to get my code to work, although now that I know that it actually is an instance of an exception it really isn't needed since I will just test for an exception.  =)

Logged In: YES 
user_id=357491

I played around today and discovered what was confusing me on all of this.  Executing the following code::

 exc = None
 try: raise Exception('blah')
 except Exception, thing: global exc; exc = thing

which causes type(exc) == <type 'instance'>.  But if you change the 'except' line to::

 except Exception, (thing,): ...

then type(exc) == <type 'str'>.  Obviously when you have a tuple as the target it is unpacking the arguments in the exception (i.e., it is just ``<target> = <raised exception>``).  I just wasn't viewing it as an assignment.  I guess the line "exception's parameter is assigned to the target" from the reference manual threw me; I thought it literally meant the parameters to the exception period, not only if there was assignment unpacking.

So since this seems to be another case of my quirky common sense not thinking like most people, should this bug report be closed or deleted?

Logged In: YES 
user_id=357491

Forgot to mention that I opened patch #726751 to try to clarify.

Logged In: YES 
user_id=31435

I'm going to put this report of its misery for you <wink>.  
Everything is working as designed here, and won't be 
changed, so there's no point keeping it open.

Note:

>>> e = Exception(1, 2, 3)
>>> list(e)
[1, 2, 3]
>>> a, b, c = e
>>> a, b, c
(1, 2, 3)
>>>

The detail part of an except clause is an assignment target 
like any other assignment target, and the only magic here is 
that Exception decided to make its instances iterable 
objects, producing the constructor's arguments.  Everything 
else follows from that.