Code review comment for lp:~ryorke/bzr/140563-optparse-barfs-on-unicode

Sorry Rory, looked at this in rather a rush and drew the wrong conclusion. Well done for investigating and finding out the problem was me being weird and running Python 2.4 and not me being weird and running windows.

> On Windows/Python 2.7, four of the five tests are skipped; each one's for a
> different user encoding. This seems to be unrelated to command options, but
> is something to do with a path:

This is something else I should have mentioned, you don't really want to put your test there, as you don't need the weird locale fiddling. How about bzrlib.tests.blackbox.test_exceptions instead?

> On Windows/Python 2.4, the test errors out spectacularly with a
> UnicodeEncodeError (assume this is what you referred to).

Yep.

> I'm not sure what to do. One possibility is allowing either error form ("only
> ascii" and "no such option"); in this case the test passes everywhere.

Well, you could either skip or just check the different output on `sys.version_info < (2, 5)` as that's where the optparse bug seems to have been introduced.

> I don't understand your suggestion. What's the "nix path"?

Rather moot now, but I was wondering if the decode step could be moved after the optparse step on posix systems as the command line is 8 bit natively there whereas it's 16 bit natively on modern windows systems.