One more "t" replaced by "U".

Unicode is confirmed "newline-safe".

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