[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH]merge_tests.py test 4 fails on trunk as a result of r22510

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2006-12-03 11:45:24 CET

Kamesh Jayachandran wrote:
> Hi Lieven,
>> In python when you use '\n' that's automatically converted to CR, LF
>> or CRLF
>> depending on the platform. os.linesep is '\r\n' on Windows, but
>> because \n is
>> converted actually it becomes '\r\r\n'. You probably only use
>> os.linesep when
>> writing in binary mode to files.
> Is it so? I believe windows libc would write LF as CRLF to disk for
> non-binary mode. I believe python should treat LF as LF and CRLF as
> CRLF. It has no business of converting the data.
Python uses the standard libc/msvcrt behavior, there's no additional
newline conversions in python.
> I don't have a access to win32 now.
> Can you tell me the out of the following code?
> Open a notepad and write abc.txt with the following snipped content.
> <snip>
> line1
> line2
> </snip>
> f = open('abc.txt')
> print len(f.read())
> If it prints '12' my theory would be:
> 'No need to bother about EOL styles, if the file is created and
> consumed by the same platform'
No, it's 14, including the two spaces after line1 and line2. The
newlines are counted as 1 byte. In a binary editor it looks like this:
line1 [CR][LF]
line2 [CR][LF]
 when working with files in text mode, python automatically handles
platform-specific newline expansion for you. If you'd open the file in
binary mode the CR and LF will both be counted.

Have a look at the eol style handling tests in merge_tests.py for the
(ugly) ways to handle multi-platform eol styles in python.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 3 11:46:02 2006

This is an archived mail posted to the Subversion Dev mailing list.