svn+ssh://pythondev@svn.python.org/python/trunk
........
r77989 | antoine.pitrou | 2010-02-05 18:05:54 +0100 (ven., 05 févr. 2010) | 6 lines
Issue #5677: Explicitly forbid write operations on read-only file objects,
and read operations on write-only file objects. On Windows, the system C
library would return a bogus result; on Solaris, it was possible to crash
the interpreter. Patch by Stefan Krah.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67908 | skip.montanaro | 2008-12-22 21:30:15 -0600 (Mon, 22 Dec 2008) | 4 lines
As a result of a regression that snuck into 2.5.3 add a test case that
ensures that when you try to read from a file opened for writing an IOError
is raised.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67666 | jeffrey.yasskin | 2008-12-08 10:55:24 -0800 (Mon, 08 Dec 2008) | 3 lines
Issue 4597: Fix several cases in EvalFrameEx where an exception could be
"raised" without setting x, err, or why to let the eval loop know.
........
r67685 | jeffrey.yasskin | 2008-12-09 23:35:02 -0800 (Tue, 09 Dec 2008) | 2 lines
Update Misc/NEWS for r67666.
........
close() will now raise an IOError if any operations on the file object
are currently in progress in other threads.
Most code was written by Antoine Pitrou (pitrou). Additional testing,
documentation and test suite cleanup done by me (gregory.p.smith).
Fixes issue 815646 and 595601 (as well as many other bugs and
references to this problem dating back to the dawn of Python).
test clean up after itself appears to fix the test failures
when test_optparse follows test_file.
test_main(): Get rid of TESTFN no matter what. That's
also enough to fix the mystery failures. Doesn't hurt
to fix them twice :-)
Since test_file is implicated in mysterious test failures
when followed by test_optparse, if I had any brains I'd
look at the checkin that last changed test_file ;-)
like cause the interpreter to exit abruptly. If there's a way to fix this,
it would be good to really fix it. It could just be the operation of the
std C library and we just aren't supposed to do that.
When the test case is skipped, we print a message so the user can check
for themselves.
test_file to fail on Windows in reality (can't delete
a still-open file), but a new bare "except:" hid that
test_file failed on Windows, and leaving behind the
still-open TESTFN caused a cascade of bogus failures
in later tests.
So, close the file, and stop hiding failure to unlink.
readline/readlines/read/readinto, loudly break by raising ValueError, rather
than silently deliver data out of order or hitting EOF prematurely.
Probably not a bugfix candidate, even though it affects no 'working' code.
close() calls would attempt to free() the buffer already free()ed on
the first close(). [bug introduced with patch #788249]
Making sure that the buffer is free()ed in file object deallocation is
a belt-n-braces bit of insurance against a memory leak.
file_truncate(): C doesn't define what fflush(fp) does if fp is open
for update, and the preceding I/O operation on fp was input. On Windows,
fflush() actually changes the current file position then. Because
Windows doesn't support ftruncate() directly, this not only caused
Python's file.truncate() to change the file position (contra our docs),
it also caused the file not to change size.
Repaired by getting the initial file position at the start, restoring
it at the end, and tossing all the complicated micro-efficiency checks
trying to avoid "provably unnecessary" seeks. file.truncate() can't
be a frequent operation, and seeking to the current file position has
got to be cheap anyway.
Bugfix candidate.
imports of test modules now import from the test package. Other
related oddities are also fixed (like DeprecationWarning filters that
weren't specifying the full import part, etc.). Also did a general
code cleanup to remove all "from test.test_support import *"'s. Other
from...import *'s weren't changed.
message for bad mode argument -- so that it doesn't fail on Windows.
It's hack. We know that errno is set to 0 in this case on Windows, so
check for that specifically.
and replaces them with a new API verify(). As a result the regression
suite will also perform its tests in optimization mode.
Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.