homepage

Working in Japan, I find it very helpful to be able to read full Unicode arguments in Python 2.x under Windows 2000/XP. So I am using the following:
http://stackoverflow.com/questions/846850/how-to-read-unicode-characters-from-command-line-arguments-in-python-on-windows/846931#846931
Brilliantly, the optparse module in Python 2.6 has worked fine with Unicode arguments. Sadly, it seems Python 2.7 is preventing this. When I try to run my program with Python 2.7, I get the following:
 ...
 File "c:\python27\lib\optparse.py", line 1018, in add_option
 raise TypeError, "invalid arguments"
TypeError: invalid arguments
It seems that the type check in optparse.py line 1018 has changed from this in 2.6:
 if type(args[0]) in types.StringTypes:
to this in 2.7:
 if type(args[0]) is types.StringType:
This makes it more difficult to support Unicode in 2.7, compared to 2.6. Any chance this could be reverted?

My program currently uses ASCII options, so I can change the Unicode string parameter to byte string. The optparse module still seems to match the option against the incoming Unicode argv, I guess by implicit string conversion.

To further explain, I had code e.g.:
 parser.add_option(u'-s', u'--seqfile', dest='seq_file_name', help=u'Write sequence file output to FILE', metavar=u'FILE')
I had to remove the unicode designator for the first parameter:
 parser.add_option('-s', u'--seqfile', dest='seq_file_name', help=u'Write sequence file output to FILE', metavar=u'FILE')
On further investigation, it looks as though the optparse module has other problems with Unicode: e.g. if I try to set a non-ASCII parameter on the command line e.g.:
 myprog.py -本
Then optparse can't handle that--it gets an encoding error on line 1396.
What _does_ work is that an option's parameters can be Unicode:
 myprog.py -s 本.txt
So I guess there are broader problems than the specific 2.6 to 2.7 change that I originally reported.

Too bad you didn't find this on one of the RCs. The fix will have to wait for 2.7.1 now.
The line you originally quote as changing was, as far as I can tell, the original code (it enters our repository on 2006年04月22日 in r45654 when optparse was upgraded to version 1.5.1 of optik). The change to the plural form in that line was made for 2.6rc1 in r71345, possibly inadvertently since that changeset was the bump to rc1.
It would seem reasonable to change this to match 2.6 for 2.7.1, since as far as I know no bugs have been reported against it in 2.6, and it is unlikely to break working code in 2.7.
As for the more extensive problems, now that argparse is part of the standard library it would seem better to devote any development resources to it. Can you test your issues against argparse, and open a new issue if it also has problems?

Regression fixed in r82581. It would be nice to have a unit test, so I'm leaving this open to see if anyone wants to contribute one (it could probably be reused for argparse if argparse doesn't already have such a test).

Created a unit test for the patch that was committed in r82581. I can easily add the test to argparse too, if needed; I didn't see any tests related to Unicode in there.

@Michael: Thanks for working on this. I don't see a patch attached to the issue, though.

Huh, let me try that again! I'm not sure how the attachment got dropped.

New changeset 4c86a860e3d2 by R David Murray in branch '2.7':
#9161: add test for the bug fixed by r82581.
http://hg.python.org/cpython/rev/4c86a860e3d2 

Thanks!

New changeset ffd70c371fee by R David Murray in branch '2.7':
#9161: Fix test to use standard optparse test pattern (what was I thinking?)
http://hg.python.org/cpython/rev/ffd70c371fee