Comment 3 for bug 1195783

@Toshi: Thanks a lot for you rhard work here and sorry for the delay !

I think there may be a simpler way to address this issue.

> This is a problem because StreamWriter objects can only handle unicode
> input (in the non-ascii range)

Then I think we should just provide it unicode no ?

We've been trying to use only unicode internally and get away with magical
auto-conversion (there is a long history being this choice, mgz is the most
knowledgeable in this area and will correct me if I'm wrong). In a nutshell,
the policy is to chose the encoding as close as possible to where it's
needed.

So, I think the fix should be to consider the content of the platform file
as being utf-8 and be done.

> I'm not submitting this as a patch because most projects have their own
> helper function that does the unicode transformation and their own
> policies on what the default encoding should be (utf-8 and the user's
> locale setting being the top two choices I've seen).

Right, the locale matters for the output but the root cause here is the
input.

Can you test the following patch:

=== modified file 'bzrlib/version.py'
--- bzrlib/version.py 2011-12-19 13:23:58 +0000
+++ bzrlib/version.py 2013-07-06 08:51:29 +0000
@@ -66,7 +66,8 @@

     to_file.write(" Python standard library:" + ' ')
     to_file.write(os.path.dirname(os.__file__) + '\n')
- to_file.write(" Platform: %s\n" % platform.platform(aliased=1))
+ to_file.write(" Platform: %s\n"
+ % platform.platform(aliased=1).decode('utf8'))