> That seems a bit *too* strict to me, as long as the Unicode strings > contain just ASCII. I'm fine with fixing both cases Barry mentioned, > especially if it otherwise breaks "from __future__ import > unicode_literals". I expect though that as one tries more things one > will find more things broken with that mode. Of course, the proposed patch would widen it to arbitrary Unicode command options; nothing in the patch restricts it to pure ASCII. Even when only ASCII characters are used in the option name, we might still get encoding exceptions or warnings if a non-ASCII byte string (e.g. from the command line) happens to be compared with the option name (although I just now couldn't produce such a case). Regards, Martin P.S. optparse already defines a function isbasestring; it might be better to use that one instead.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4