- Fixed a typo

- Return a tuple of newlines in stead of 'mixed'
- Added rationale for having the code in ifdefs and not having the
  newlines attribute in --without-universal-newlines builds.

pep-0278.txt

@@ -30,7 +30,7 @@ Abstract
 
 Specification
 
-    Universal newline support needs to be enabled by default,
+    Universal newline support is enabled by default,
     but can be disabled during the configure of Python.
     
     In a Python with universal newline support the feature is
@@ -49,13 +49,13 @@ Specification
     readline(), readlines(), etc.
     
     There is no special support for output to file with a different
-    newline convention.
+    newline convention, and so mode "wU" is also illegal.
     
     A file object that has been opened in universal newline mode gets
     a new attribute "newlines" which reflects the newline convention
     used in the file.  The value for this attribute is one of None (no
-    newline read yet), "\r", "\n", "\r\n" or "mixed" (multiple
-    different types of newlines seen).
+    newline read yet), "\r", "\n", "\r\n" or a tuple containing all the
+    newline types seen.
 
     
 Rationale
@@ -161,6 +161,16 @@ Rationale
     Note that no globally accessible pointers are manipulated in the
     fgets() or fread() replacement routines, just some integer-valued
     flags, so the chances of core dumps are zero (he said:-).
+    
+    Universal newline support can be disabled during configure because it does
+    have a small performance penalty, and moreover the implementation has
+    not been tested on all concievable platforms yet. It might also be silly
+    on some platforms (WinCE or Palm devices, for instance). If universal
+    newline support is not enabled then file objects do not have the "newlines"
+    attribute, so testing whether the current Python has it can be done with a
+    simple
+    if hasattr(sys.stdout, 'newlines'):
+    	print 'We have universal newline support'
 
     
 Reference Implementation