On 28/06/2011 18:06, Terry Reedy wrote:
On 6/28/2011 10:46 AM, Paul Moore wrote:
I use Windows, and come from the UK, so 99% of my text files are
ASCII. So the majority of my code will be unaffected. But in the
occasional situation where I use a £ sign, I'll get encoding errors,
I do not understand this. With utf-8 you would never get a string
encoding error.
I assumed he meant that files written out as utf-8 by python would then
be read in using the platform encoding (i.e. not utf-8 on Windows) by
the other applications he is inter-operating with. The error would not
be in Python but in those applications.
where currently things will "just work".
As long as you only use the machine-dependent restricted character set.
Which is the situation he is describing. You do go into those details
below, and which choice is "correct" depends on which trade-off you want
to make.
For the sake of backwards compatibility we are probably stuck with the
current trade-off however - unless we deprecate using open(...) without
an explicit encoding.
All the best,
Michael
> And the failures will be data dependent, and hence intermittent
> (the worst type of problem).
That is the situation now, with platform/machine dependencies added in.
Some people share code with other machines, even locally.
So, in effect, you propose making the default favour writing
multiplatform portable code at the expense of quick and dirty scripts?
Let us frame it another way. Should Python installations be compatible
with other Python installations, or with the other apps on the same
machine? Part of the purpose of Python is to cover up platform
differences, to the extent possible (and perhaps sensible -- there is
the argument). This was part of the purpose of writing our own io
module instead of using the compiler stdlib. The evolution of floating
point math has gone in the same direction. For instance, float now
expects uniform platform-independent Python-dependent names for
infinity and nan instead of compiler-dependent names.
As for practicality. Notepad++ on Windows offers ANSI, utf-8 (w,w/o
BOM), utf-16 (big/little endian). I believe that ODF documents are
utf-8 encoded xml (compressed or not). My original claim for this
proposal was/is that even Windows apps are moving to uft-8 and that
someday making that the default for Python everywhere will be the
obvious and sensible thing.
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
_______________________________________________
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
