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
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
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 tuple of up to three elements
> > giving the actual line endings that
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 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
Paul Moore schrieb:
> Specifically, I'm looking to replicate this behaviour:
>
>>xxd crlf
> 000: 610d 0a62 0d0a a..b..
>
>>xxd lf
> 000: 610a 620aa.b.
>
>>python
> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 b
On 11/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/11/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > Is this ok: when newline='\r\n' or newline='\r' is passed, only that
> > string is used to determine
> > the end of lines. No translation to '\n' is done.
>
> I *think* it would be more
On Aug 11, 2007, at 10:29 AM, Guido van Rossum wrote:
>> Is this ok: when newline='\r\n' or newline='\r' is passed, only that
>> string is used to determine
>> the end of lines. No translation to '\n' is done.
>
> I *think* it would be more useful if it always returned lines ending
> in \n (not \r
On 8/11/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> On Aug 10, 2007, at 11:23 AM, Guido van Rossum wrote:
>
> > Python 3.0 currently has limited universal newlines support: by
> > default, \r\n is translated into \n for text files, but this can be
> > controlled by the newline= keyword parameter
On Aug 10, 2007, at 11:23 AM, Guido van Rossum wrote:
> Python 3.0 currently has limited universal newlines support: by
> default, \r\n is translated into \n for text files, but this can be
> controlled by the newline= keyword parameter. For details on how, see
> PEP 3116. The PEP prescribes that
Guido van Rossum writes:
> However, the old universal newlines feature also set an attibute named
> 'newlines' on the file object to a tuple of up to three elements
> giving the actual line endings that were observed on the file so far
> (\r, \n, or \r\n). This feature is not in PEP 3116, and
12 matches
Mail list logo