RetroSearch Browse

Mon Aug 10 03:07:45 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-August/091103.html

> M.-A. Lemburg wrote:

>> ... and because of this, the feature is already available if
>> you use codecs.open() instead of the built-in open():

Neil Hodgson asked:
> So should I not add an issue for the basic open because codecs.open
> should be used for this case?

In python 3, why does codecs.open even still exist?

As best I can tell, codecs.open should be the same as regular open,
but for a unicode file -- and all text files are treated as unicode in
python 3.0

So at this point, are there any differences beyond:

(a)  The builtin open doesn't work on multi-byte line-endings other
than the multi-character CRLF.  (In other words, it goes by the
traditional Operating System conventions developed when a char was a
byte, but the Unicode standard allows for a few more possibilities,
which are currently rare in practice.)

(b)  The codecs version is much slower, because it hasn't seen the
optimization effort.

-jJ

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-August/091103.html below:

[Python-Dev] codecs.oen [was: PEP 385: the eol-type issue]