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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4