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

[Steven Bethard]

On 9/29/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Steven Bethard wrote:
> > On 9/29/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> >
> >> Terry Reedy wrote:
> >>
> >>> There are two normal ways for internal Python text to have \r\n:
> >>> 1. Read from a file with \r\r\n.  Then \r\r\n is correct output (on the
> >>> same platform).
> >>> 2. Intentially put there by a programmer.  If s/he also chooses default \n
> >>> translation on output, \r<translation of \n> is correct.
> >>>
> >>>
> >> Actually, I usually get these strings from Windows UI components. A file
> >> containing '\r\n' is read in with '\r\n' being translated to '\n'. New
> >> user input is added containing '\r\n' line endings. The file is written
> >> out and now contains a mix of '\r\n' and '\r\r\n'.
> >
> > Out of curiosity, why don't the Python wrappers for your Windows UI
> > components do the appropriate '\r\n' -> '\n' conversions?
>
> One of the great things about IronPython is that you don't *need* any
> wrappers - you access .NET objects natively (which in fact wrap the
> lower level win32 API) - and the .NET APIs are usually not as bad as you
> probably assume. ;-)
>
> You just have to be aware that line endings are '\r\n'.

Ahh, I see.  So all the .NET components function like Python 3.0's
io.open(..., newline='\n'), where no translation of \n (to or from
\r\n) is performed.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy