Exception.__str__ seems to contain a bug that causes it
to not handle errors correctly. To reproduce the
problem, type the following lines into a Python
interpreter:

  ex = Exception()
  ex.args = None
  str(ex)
  d = {}

Note that we set Exception.args to None, while the
__str__ method expects args to be a sequence. The
interpreter, however, prints "'None'", and no error is
shown. But when trying to excecute the perfectly
harmless 'd = {}' assignment, an error, with *no
traceback* is printed an 'd' is never defined.

I have not been able to recreate this bug in a simple
script yet, though it was found through a large Zope
application where a client had created a custom
Exception with self.args set to None. The above
behaviour has been observed in Python versions 2.1.3,
2.2.1 and current CVS, but not in Python 1.5.2.

Logged In: YES 
user_id=33168

The problem is in Python/exceptions.c at the switch
statement, line 278 or so.  If PySequence_Size() returns -1
(since args is None), the default case is handled, but an
exception was set.  The string is returned and printed as
'None', but an exception still exists.  The next instruction
(d = {}) show's the exception.

I would tend to say it's best to ignore the error (treat as
empty args).  If so, adding case -1: which calls
PyErr_Clear() and then falls through to case 0: seems to
work for me.

Note:  there are 2 other simlar swiches in
Python/exceptions.c.  SystemExit__init__ &
EnvironmentError__init__

Guido, assign back to me if you want me to fix it.  And let
me know how this problem should be handled.

Logged In: YES 
user_id=6380

Thanks, both! Fixed in the CVS trunk, labeled as a backport
candidate.

Logged In: YES 
user_id=33168

Guido, should the other 2 switches be fixed too?  (see
bottom of my message)

Logged In: YES 
user_id=6380

Yes, please fix those too! Sorry for shooting too fast. :-)

Logged In: YES 
user_id=33168

Checked in the other 2 fixes as Python/exceptions.c 1.40.

Logged In: YES 
user_id=116747

Heh, but the two cases of your checkin were both in __init__
methods, where the args tuple in question was created with a
PySequence_GetSlice call (lines 404 and 471 in 1.40) with
the function arguments as source sequence and thus will
always be a sequence when the PySequence_GetSlice succeeds.

Seems to me Guido's checkin was sufficient to solve this
particular bug.

Logged In: YES 
user_id=33168

You are correct that Guido's checkin was sufficient for this
bug.  The other 2 cases *should* never happen.  It is
defensive, in case something unexpected should go wrong.