Richie Hindle <richie at entrian.com> wrote in message news:<mailman.1063967785.18911.python-list at python.org>... > [Peter] > > I wonder if the function *tell()* is not correctly implemented under win32. > > [M-a-S] > > Anyway, you program works under Windows XP/Python 2.3 as expected: > > M-a-S, are you sure you saved test_data.txt with Unix line endings? I This is exactly the point. It works under win32 with PC-endings, but not with Unix line endings. The workaround is to open it in binray mode. I know there are differences between the open-modes 'rb', 'r+b' ... but that's not the problem. Both work fine. > tested Peter's script under WinXP/Python2.3 as well, and it failed as > expected (though with slightly different results): > > >pythonw -u peter.py > Filepointer: 0 > Filepointer: 8 It doesn't make any sense for me that file position results in *8* here. The line has 10 chars: 0123456789 plus one newline which makes 11 for me if newline is only a 0xa and 12 if newline is a 0xc, 0xa. So let's suppose the *file(file_name).readline()* reads until it detects a 0xa and then subtracts an os-depending number of bytes namely one for UNIX-newline and two for PC-newline. Then it would result in 10 or 9 but never in 8. It doesn't make any sense for me. I think it must be a bug. > Filepointer: 20 > Filepointer: 31 > Filepointer: 50 > > Filepointer: 0 > Filepointer: 11 > Filepointer: 22 > Filepointer: 32 > Filepointer: 50 When the file is opened in binary mode the above output shows that python does the right work. Peter
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4