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/
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