Using builtin exception information is tricky as it
consists of:
a) the type of exception (easily accessible)
b) the args attribute = a 1 element tuple with a string
1st example:
try:
print foo
except NameError, e:
print e.args
symbol = e.args[0][17:-16]
print symbols
==>
("NameError: name 'foo' is not defined", )
foo
It would be nicer to have:
e.args = ("NameError: name 'foo' is not defined", "foo")
The first element being the current string for backward
compatibilty.
=============================
2nd example:
try:
(4).foo
except NameError, e:
print e.args
==> ("'int' object has no attribute 'foo'",)
It would be nicer to have:
e.args = ("'int' object has no attribute 'foo'", 4, "foo")
Again, the first element being the current string for
backward compatibilty.
=============================
Moreover, in the documentation about Exception, I read
"""Warning: Messages to exceptions are not part of the
Python API. Their
contents may change from one version of Python to the
next without warning
and should not be relied on by code which will run under
multiple versions
of the interpreter. """
So even args could not be relied upon !
But it also means that there is no need to be backward
compatible (I am playing devil's advocate, backward
compatibility is important !)
Seb
ps: There may be problems (that I am not aware) with
a) an exception keeping references to other objects
b) C API that can throw only exceptions with strings
c) a specific advantage of having strings only in builtin
exceptions

Logged In: YES
user_id=89016
+1
This should probably be part of Brett's Py3000 exception PEP.
Candidates I can think of are:
KeyError(obj=..., key=...)
IndexError(obj=..., index=...)
IOError(file=..., code=...)
NameError(name=...)
Regenerating the message would be done with __str__().
I'm not sure how this would work on the level of the C API.

Beware that making exceptions hold on arbitrary objects increases the
possibility of delayed collection and reference cycles, though.
(especially in trunk where the "current" exception can last after the
end of an except block)

Thanks for the response.
In terms of python API changes - I exposed the 'name' attribute on UnboundLocalError and NameError exceptions.
(This can be seen (& is verified) by the changes to test_exceptions.py exceptions test cases in the patch)
In terms of the wider changes in the patch - I factored UnboundLocalError and NameError to have specific native implementations, rather than been based off SimpleExtendsException. And thus able to accept the name of the variable causing the exception.
And I agree with your comment on the exact API never been agreed on. Since there are now native implementations of UnboundLocalError and NameError, I can happily change their implementation to expose whatever can be decided to be better (comments?!)
Thanks, George