Ezio Melotti <ezio.melo...@gmail.com> added the comment:
I've also noticed that if an error contains non-encodable characters,
they are escaped:
>>> raise ValueError("\u2620 can't be printed here, but '\u00e8' works
fine!")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: \u2620 can't be printed here, but 'รจ' works fine!
but:
>>> "\u2620 can't be printed here, but '\u00e8' works fine!"
UnicodeEncodeError: 'charmap' codec can't encode character '\u2620' in
position 1: character maps to <undefined>
The mechanism used to escape errors is even better than my patch,
because it escapes only the chars that can't be encoded, instead of
escaping every non-ascii chars when at least one char can't be encoded:
>>> "\u2620 can't be printed here, but '\u00e8' works fine!"
"\u2620 can't be printed here, but '\xe8' works fine!"
I wonder if we can reuse the same mechanism here.
By the way, the patch I proposed in msg80852 is just a proof of concept,
if you think it's OK, someone will probably have to implement it in C.
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5110>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
