Josh Rosenberg added the comment:
Based on the OP's patch, it looks like they have a problem where they have
non-ASCII text in their output strings (either due to using non-ASCII switches,
or using non-ASCII help documentation), but sys.stdout/sys.stderr are
configured for some encoding that doesn't support said characters, so they're
getting exceptions when the help message is sent to the screen automatically
(e.g. by running with --help).
It's only sort of a bug in Python: Fundamentally, the problem is a script that
assumes arbitrary Unicode support being run under a locale that doesn't provide
it. The solution provided is bad though: It shouldn't be trying to force UTF8
output regardless of locale.
A simple repro, at least on Linux-like systems, would be to run Python with
LANG=C (and no other LC variables set), then do:
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('-f', help=chr(233)) # help is 'é'
parser.print_help()
While the patch as given is wrong (with the exception of Windows weirdness,
blithely ignoring/second-guessing the locale is a terrible idea), it's not a
terrible idea to fix this in some way; if nothing else, it might make sense to
have some fallback approach when the exception is raised (e.g. encoding the
output with errors='ignore' or the like) so running scriptname.py --help at
least provides *some* output even with incompatible locales, rather than dying
with an error in the help message handling code itself.
----------
nosy: +josh.r
status: pending -> open
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31475>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
