From 19aefb350013d2563ab6564e794f879bb615d06e Mon Sep 17 00:00:00 2001 From: Jack Jansen Date: Sat, 16 Mar 2002 00:35:36 +0000 Subject: [PATCH] One more "t" replaced by "U". Unicode is confirmed "newline-safe". --- pep-0278.txt | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/pep-0278.txt b/pep-0278.txt index 2ee5df640..fd73dd59f 100644 --- a/pep-0278.txt +++ b/pep-0278.txt @@ -110,12 +110,8 @@ Rationale I think there are no special issues with unicode. utf-16 shouldn't pose any new problems, as such files need to be opened in binary - mode anyway. Interaction with utf-8 I am not 100% sure about: is it - possible for a 0x0a or 0x0d byte to occur as part of a multibyte - escape without the stadnard meaning of CR or LF? I assume not, - because if such bytes are allowed it would mean that readline() on - Unix would terminate the read on a 0x0d (and on MacOS on a 0x0a) - without a full line being read. + mode anyway. Interaction with utf-8 is fine too: values 0x0a and 0x0d + cannot occur as part of a multibyte sequence. Universal newline files should work fine with iterators and xreadlines() as these eventually call the normal file @@ -124,7 +120,7 @@ Rationale While universal newlines are automatically enabled for import they are not for opening, where you have to specifically say open(..., - "t"). This is open to debate, but here are a few reasons for this + "U"). This is open to debate, but here are a few reasons for this design: - Compatibility. Programs which already do their own