Robert Collins <robe...@robertcollins.net> added the comment:
"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.
"
I'm not sure how you justify raising an unnecessary error when trying to
stringify an exception as being 'better'.
__str__ should not decode its arguments if they are already strings:
they may be valid data for the user even if they are not decodable (and
note that an implicit decode may try to decode('ascii') which is totally
useless.
__str__ and __unicode__ are /different/ things, claiming they have to
behave the same is equivalent to claiming either that we don't need
unicode, or that we don't need binary data.
Surely there is space for both things, which does imply that
unicode(str(e)) != unicode(e).
Why _should_ that be the same anyway?
----------
nosy: +rbcollins
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
