On 23 Jan 2010, at 07:53, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
[snip...]
Yes, definitely. It is this very reasoning that caused Python 2.x to
use ASCII as the default encoding (when mixing strings and unicode),
and, for the entire lifetime of 2.x, has caused endless pain for
developers, which simply fail to understand the notion of encodings
in the first place. The majority of developers is unable to get it
right, in particular if their native language is English. These
developers just hate Unicode. They google for solutions, and come
up with all kinds of proposals which are all wrong (such as reloading
the sys module to get back sys.setdefaultencoding, to then set it
to UTF-8).
So for the limited case of text IO, Python 3.x now makes a guess.
However, this guess is not in the face of ambiguity: it is the
locale that the user (or his administrator) has selected, which
identifies the language that they speak and the character encoding
they use for text. So if Python also uses that encoding, it's not
really an ambiguous guess.
However it is likely to be often wrong, and where the user's locale
specifies an encoding like CP1252 then it will result in silent
corruption rather than an immediate exception.
This is why I'm keen that by *default* Python should honour the UTF8
signature when reading files; particularly given that programmers who
don't/can't/won't understand encodings are likely to read files
without specifying an encoding and a lot of the time it will *seem* to
work.
Michael
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
