open() in binary vs. text mode

Tim Peters at
Fri Mar 21 21:04:54 CET 2003

[Bob Roberts]
> This problem does not appear to have anything to do with the \r\n vs.
> \r vs \n problem.
> When in windows, reading in text mode, if it came across ASCII
> character 26, it would quit and not read any more of the file.  This
> does not happen on other platforms or on windows when reading in
> binary mode.
> Why would a specific character cause this behavior?

Backward compatibility with DOS 1.0, which didn't save the sizes of files in
the system file directory.  They needed some other way to recognize the end
of a file, and picked on Ctrl+Z (chr(26)) to mean EOF.  This is specific to
CPM and DOS derivatives (like Windows), AFAIK.

It's fine by the ANSI C standard, BTW:  the distinction between text mode
and binary mode is part of standard C, and I/O on text mode files is
essentially undefined if you print any characters outside of printable 7-bit
ASCII, tab, and newline.  The idea that text mode and binary mode is the
same is universal across Unix variants, but I think historically rare before

More information about the Python-list mailing list