[Python-Dev] Please review PEP 278 - Universal newline support

Just van Rossum just@letterror.com
Fri, 8 Mar 2002 16:57:02 +0100


Greg Ward wrote:

> -1 on using a file mode character that conflicts with existing
> conventions (eg. if "t" really is already used on Windows, find
> something else).

The "t" isn't really needed to begin with, files opened in text mode should
convert any line ending to \n. One of Jack's arguments _for_ "t" is:

    - Compatibility.  Programs which already do their own
      interpretation of \r\n in text files would break.  Programs
      which open binary files as text files on Unix would also break
      (but it could be argued they deserve it :-).

I don't understand the first bit, but my opinion on the latter bit is "they
deserve it". However this problem can also be circumvented by having the feature
*off* by default on those platforms.

This is Jack's second argument for a "t" mode:

    - Interface clarity.  Universal newlines are only supported for
      input files, not for input/output files, as the semantics would
      become muddy.  Would you write Mac newlines if all reads so far
      had encountered Mac newlines?  But what if you then later read a
      Unix newline?

I think you can simply substitute the platform line ending when writing a \n. I
don't know, but I wouldn't worry too much about read/write mode. If you're going
to write to one text file from different platforms you're going to have to
settle for one convention anyway, and that then might as well be \n & binary
mode... An alternative might be a settable lineending attribute.

Just