On 9/29/07, Nick Maclaren <nmm1@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