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 text.
-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
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
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 were
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 tuple of up to three
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 bit
(Intel)]
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 with
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 a
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. For
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\n or
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 it
11 matches
Mail list logo
