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.
Lieven
---------------------------------------------------------------------
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