[Python-Dev] Please review PEP 278 (original) (raw)

[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