[Python-Dev] Internationalization Toolkit (fwd)

Greg Stein gstein@lyra.org
Thu, 11 Nov 1999 04:20:39 -0800 (PST)


Andy originally sent this just to me... I replied in kind, but saw that he
sent another copy to python-dev. Sending my reply there...

---------- Forwarded message ----------
Date: Thu, 11 Nov 1999 04:00:38 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: andy@robanal.demon.co.uk
Subject: Re: [Python-Dev] Internationalization Toolkit

[ note: you sent direct to me; replying in kind in case that was your
  intent ]

On Wed, 10 Nov 1999, [iso-8859-1] Andy Robinson wrote:
>...
> Let me tell you why you would want to have an encoding
> which can be set:
>...snip: two examples of how "print" fails...

Neither of those examples are solid reasons for having a default encoding
that can be changed. Both can easily be altered at the Python level by
using an encoding function before printing.

You're asking for convenience, *not* providing a reason.

> Java solves this (and we could too) using Writer
> classes which are created as wrappers around an output
> stream and can take an encoding, but you lose the
> flexibility to just print.  

Not flexibility: convenience. You can certainly do:

  print encode(u,'Shift-JIS')

> I think being able to change encoding would be useful.
>  What I do not want is to auto-detect it from the
> operating system when Python boots - that would be a
> portability nightmare. 

Useful, but not a requirement.

Keep the interpreter simple, understandable, and predictable. A module
that changes the default over to 'utf-8' because it is interacting with a
network object is going to screw up your app if you're relying on an
encoding of 'shift-jis' to be present.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/