As Guido said, Java defines that source-code lines end with any of LF, CR, or CRLF, and that needn't even be consistent across lines. If source files are opened in C binary mode, this is easy enough to do but puts all the burden for line-end detection on Python. Opening source files in C text mode doesn't solve the problem either. For example, if you open a source file with CR endings in Windows C text mode, Windows thinks the entire file is "one line". I expect the same is true if CR files are opened in Unix text mode. So, in the end, binary mode appears to be better (more uniform code). But then what happens under oddball systems like OpenVMS, which seem to use radically different file structures for text and binary data? I've no idea what happens if you try to open a text file in binary mode under those. [Guido]
... It would also be nice if opening a file in text mode did this transformation, but alas, that would probably require more work on the file object than I care for.
Well, Python source files aren't *just* read by "the compiler" in Python. For example, assorted tools in the std library analyze Python source files via opening as ordinary (Python) text files, and the runtime traceback mechanism opens Python source files in (C) text mode too. For that stuff to work correctly regardless of line ends is lots of work in lots of places. In the end I bet it would be easier to replace all direct references to C textfile operations with a "Python text file" abstraction layer. importing-is-only-the-start-of-the-battle-ly y'rs - tim