What you said is only a special case, and I agree that the solution
introduced with r64791 is correct for that. However, that fix has the
side effect of breaking the code in other situations.


To summarize the possible cases and the behaviours I prepared the
following list (odd numbers -> BaseException; even numbers -> any
exception with overridden __str__ and no __unicode__.):
1) 0 args, e = Exception():
   py2.5  : str(e) -> ''; unicode(e) -> u''
   py2.6  : str(e) -> ''; unicode(e) -> u''
   desired: str(e) -> ''; unicode(e) -> u''
Note: this is OK

2) 0 args, e = MyException(), with overridden __str__:
   py2.5  : str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
   py2.6  : str(e) -> 'ascii' or error; unicode(e) -> u''
   desired: str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
Note: py2.5 behaviour is better: if __str__ returns an ascii string
(including ''), unicode(e) should return the same string decoded, if
__str__ returns a non-ascii string, both should raise an error.

3a) 1 str arg, e = Exception('foo'):
   py2.5  : str(e) -> 'foo'; unicode(e) -> u'foo'
   py2.6  : str(e) -> 'foo'; unicode(e) -> u'foo'
   desired: str(e) -> 'foo'; unicode(e) -> u'foo'
Note: this is OK

3b) 1 non-ascii unicode arg, e = Exception(u'föö'):
   py2.5  : str(e) -> error; unicode(e) -> error
   py2.6  : str(e) -> error; unicode(e) -> u'föö'
   desired: str(e) -> error; unicode(e) -> u'föö'
Note: py2.6 behaviour is better: unicode(e) should return u'föö'

4) 1 unicode arg, e = MyException(u'föö'), with overridden __str__:
   py2.5  : str(e) -> error or 'ascii'; unicode(e) -> error or u'ascii'
   py2.6  : str(e) -> error or 'ascii'; unicode(e) -> u'föö'
   desired: str(e) -> error or 'ascii'; unicode(e) -> error or u'ascii'
Note: py2.5 behaviour is better: if __str__ returns an ascii string
str(e) should work, otherwise it should raise an error. unicode(e)
should return the ascii string decoded or an error, not the arg.

5) >1 args of any type, e = Exception('foo', u'föö', 5):
   py2.5  : str(e) ->  "('foo', u'f\\xf6\\xf6', 5)";
        unicode(e) -> u"('foo', u'f\\xf6\\xf6', 5)";
   py2.6  : str(e) ->  "('foo', u'f\\xf6\\xf6', 5)";
        unicode(e) -> u"('foo', u'f\\xf6\\xf6', 5)";
   desired: str(e) ->  "('foo', u'f\\xf6\\xf6', 5)";
        unicode(e) -> u"('foo', u'f\\xf6\\xf6', 5)";
Note: this is OK

6) >1 args of any type, e = MyException('foo', u'föö', 5), with
overridden __str__:
   py2.5  : str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
   py2.6  : str(e) -> 'ascii' or error; unicode(e) -> u"('foo',
u'f\\xf6\\xf6', 5)";
   desired: str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
Note: py2.5 behaviour is better: if __str__ returns an ascii string,
unicode(e) should return the same string decoded, if __str__ returns a
non-ascii string, both should raise an error.

As you can see, your example corresponds just to the case 3b) (now
fixed), but cases 2, 4, 6 are now broken.

Making this list allowed me to come out with a new patch, that seems to
solve all the problems (2, 4 and 6 while leaving 3b as it is now). The
only exception is for KeyError, if we want it to print the repr, then
KeyError_unicode should be implemented, but I think that Python only
calls str() so it's probably not necessary.

Attached new patch that passes all the tests in issue6108_testcase
except for KeyError. Unless you disagree with the 'desired behaviours'
that I listed, this patch should fix the issue.