[Python-Dev] [python] Re: New lines, carriage returns, and Windows

[Nick Maclaren]

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