Barry Warsaw wrote:
> Add a flag
> called preserve_eols that defaults to False, is ignored unless
> universal newline mode is turned on,
Is there any reason it shouldn't work in non-universal-
newlines mode too?
--
Greg Ewing, Computer Science Dept, +--+
U
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 15, 2007, at 12:03 AM, Guido van Rossum wrote:
> On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Aug 14, 2007, at 12:52 PM, Guido van Rossum wrote:
>>> On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
It would have been perfec
On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 14, 2007, at 12:52 PM, Guido van Rossum wrote:
> > On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> >> It would have been perfect, I think, if I could have opened the file
> >> in text mode so that read() gave me strings, with univer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2007, at 12:52 PM, Guido van Rossum wrote:
> On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> It would have been perfect, I think, if I could have opened the file
>> in text mode so that read() gave me strings, with universal newlines
On 8/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Now, this doesn't support bare \r as line terminator, but I doubt you
> > care much about that (unless you want to port the email package to Mac
> > OS 9 :-).
>
> Haven't we decided that '\r' still occurs in some
> ca
Guido van Rossum wrote:
> Now, this doesn't support bare \r as line terminator, but I doubt you
> care much about that (unless you want to port the email package to Mac
> OS 9 :-).
Haven't we decided that '\r' still occurs in some
cases even on MacOSX?
--
Greg
___
On 8/14/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> It would have been perfect, I think, if I could have opened the file
> in text mode so that read() gave me strings, with universal newlines
> and preservation of line endings (i.e. no translation to \n).
You can do that already, by passing newl
On Tue, Aug 14, 2007 at 09:58:32AM -0400, Barry Warsaw wrote:
> This was all fine except that some of the tests started
> failing because of the EOL translation that happens unconditionally
> now. The file contained \r\n and the test was ensuring these EOLs
> were preserved in the parsed te
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2007, at 4:15 PM, Guido van Rossum wrote:
> I've seen similar behavior in MS VC++ (long ago, dunno what it does
> these days). It would read files with \r\n and \n line endings, and
> whenever you edited a line, that line also got a \r\n en
Guido van Rossum wrote:
> On 8/13/07, Russell E Owen <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>,
>> "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>>> I have run into files that intentionally have more than one newline
>>> convention used (mbox and Babyl mail folders, with mess
On 8/13/07, Russell E Owen <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> > Guido van Rossum writes:
> >
> > > However, the old universal newlines feature also set an attibute named
> > > 'newlines' on the file object to a tupl
Paul> ... that files can have *either* bare \n, *or* the combination
Paul> \r\n, to delimit lines.
As someone else pointed out, \r needs to be supported as well. Many Mac
applications (Excel comes to mind) still emit text files with \r as the line
terminator.
Skip
_
On 13/08/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > and you set the newline argument to specify a *specific*,
> > non-universal, newline value
>
> It still seems wrong to not translate the newlines, though,
> since it's still a *text* mode, and the standard Python
> represent
Paul Moore wrote:
> and you set the newline argument to specify a *specific*,
> non-universal, newline value
It still seems wrong to not translate the newlines, though,
since it's still a *text* mode, and the standard Python
representation of text has \n line endings.
--
Greg
On 12/08/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Note that Python does nothing special in the above case. For non-Windows
> platforms, you'd get two different results -- the conversion from \r\n to
> \n is done by the Windows C runtime since the default open() mode is text
> mode.
>
> Only w
15 matches
Mail list logo
