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.