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.