[Guido]
> In the most recent checkout on Linux, test_largefile.py fails. The
> output is:
>
> [guido@pcp742651pcs linux]$ ./python ../Lib/test/test_largefile.py
> ...
> try truncate
> 2500000001L =?= 2500000001L ... yes
> 2499999990L =?= 2499999990L ... yes
> 2499999990L =?= 2499999990L ... yes
> 0L =?= 2499999989L ... no
The docs promise something that may not be true, and the test (which was
commented out before yesterday) assumes something that may not be true:
1. The docs promise that truncate() will never grow the file. I don't
believe Unix ftruncate() promises that, although you got beyond
the part of the test that checks for that (so ftruncate apparently
won't grow the file on your box).
2. The test assumes truncate() leaves the file position at the
point of truncation. That's why your test is failing:
# Ensure that truncate(smaller than true size) shrinks the file.
newsize -= 1
f.seek(0)
f.truncate(newsize)
expect(f.tell(), newsize) # ***** you're failing here *****
The output shows that, on your box, the file position was left at 0. Our
docs are silent on this point.
If we want to promise that truncate() won't grow the file, I believe the
non-Windows implementation needs to change.
If we don't want to promise that truncate() won't grow the file, the docs
need to change and the Windows implementation can be made simpler.
If we want to promise that the file position won't change, the docs need to
change, Unix geeks have to investigate the truth of that on non-Windows
systems, and the Windows implementation needs to change.
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