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

Nick Maclaren nmm1 at cus.cam.ac.uk
Sun Sep 30 16:12:00 CEST 2007

Michael Foord <fuzzyman at voidspace.org.uk> wrote:

skip at pobox.com wrote:

> Michael> Actually, I usually get these strings from Windows UI > Michael> components. A file containing '\r\n' is read in with '\r\n' > Michael> being translated to '\n'. New user input is added containing > Michael> '\r\n' line endings. The file is written out and now contains a > Michael> mix of '\r\n' and '\r\r\n'. > > So you need a translation layer between the UI component and your code. > Treat the component as a text file and perform the desired mapping. Yes? Actually the problem was reported by one of the IronPython developers on behalf of another user. We stick to using the .NET file I/O and so don't have a problem. The only time it is an issue for us is our tests, where we have string literals in our test code (where new lines are obviously '\n') and we do a manual 'replace'. Not very difficult. It is just slightly ironic that the time Python 'gets it wrong' (for some value of wrong) is when you are using text mode for I/O :-)

Plus ca change, ....

That has been the problem for as long as I have been using the byte stream model (nearly 40 years now). Provided that you can get control, OR there are well-defined semantics, you can sort things out. The semantics "we define only the trivial case, and the programmer must do something arcane, undefined and system-dependent for the rest" means that it is impossible for an interface to do the 'right' translation unless it knows what each side of it is assuming.

As I say, there are solutions.

Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list