[Python-Dev] New lines, carriage returns, and Windows (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Sun Sep 30 01:46:19 CEST 2007

On 9/29/07, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:

Now, BCPL was an ancestor of C, but always was a more portable language (i.e. it didn't start with a specific operating system in mind), and used/uses a rather better model. In this, line separators are atomic - e.g. '\f' is newline-with-form-feed and '\r' is "newline-with-overprinting".

I don't see how this is different from Unix/C "\n" being an atomic newline character.

If you're saying that BCPL is better because it defines standard semantics for more control characters than just "\n", that may be true, but C is doing about the best it can with "\n" as far as I can see, given all the crazy things that different OSes want to do with line endings.

In any case, the problem which started all this isn't really an I/O problem at all, it's a mismatch between the world of Python strings which use "\n" and .NET library code expecting strings which use "\r\n".

The correct thing to do with that is to translate whenever a string crosses a boundary between Python code and .NET code. This is something that ought to be done automatically by the Python/.NET interfacing machinery, maybe by having a different type for .NET strings.

-- Greg

More information about the Python-Dev mailing list