Re: [Jython-dev] A weakness in some Python tests

[Philip J. <pj...@un...>]

On Dec 14, 2012, at 5:12 PM, Jeff Allen wrote:

> On 14/12/2012 19:09, fwi...@gm... wrote:
>> On Fri, Dec 14, 2012 at 12:59 AM, Jeff Allen<ja...py...@fa...>  wrote:
>>> Second thoughts on the below ... tearDown is called, as it should be,
>>> but in the particular test (test.test_fileio.AutoFileTests.testErrors)
>>> that was at the root of the problem, a second file object (_io.FileIO)
>>> is created on the same file and tearDown does not know about it.
>>> 
>>> A clean answer in AutoFileTests is to store each re-opened file back in
>>> self.f for closing in tearDown.
>>> 
>>> You can find a few other cases of this in the module. What I say about
>>> CPython getting away with this and Jython falling foul of it still holds.
>>> 
>>> Jeff (who even tests the tests)
>> The long term plan for Jython's standard library is for it to reside
>> in CPython's standard library (the long long term plan is for the
>> standard lib to be altogether split out from CPython)
>> 
>> Give that, these types of testing issues are good to keep track of for
>> the time that we start trying to merge our version of the standard
>> library with CPython's version. Hopefully this will get a real start
>> next year as Jython starts looking to a 3.x version. These sorts of
>> test fixes should find there way into CPython's latest default branch.
>> It's possible that you may find them already fixed there as PyPy and
>> possibly IronPython hit the same issues.
>> 
>> -Frank
> Seems I was wrong about CPython getting away with this. I can get a 
> similar cascade of errors with CPython 3.3, if I deliberately introduce 
> an error into the tests. The code is full of close and unlink 
> statements, but PyPy has exactly the same file but IronPython defines 
> its own test (which consists mostly of TODO comments). The dilemma now 
> is how thorough to be about the OtherFileTest: done properly, with setUp 
> and tearDown, quite a lot of try...finally...unlink() can be removed (I 
> think). I'll put a changeset just for this in my next push (for Jython). 
> Tempting to do the same for CPython (via the bug tracker I mean).

It sounds like you're on Windows, which exacerbates this problem. You can't remove files on Windows if any process still has an open fd on it, so things like unlink die with a hard error in cases like this. POSIX doesn't care and so it gets no error. Especially annoying when you're building the implementation of a module from scratch and are bound to have tons of errors =]

Go ahead and fix the these tests to add the proper cleanup if you'd like. Python 3.2 added a new ResourceWarning that's triggered when a file is implicitly closed, that can help you find cases like this (unfortunately we lack it for 2.7).

2.7's unittest added a nice feature for adding cleanups inside of the test case itself, a TestCase method addCleanup(). e.g. 

def test_stuff(self):
 f = open('file')
 self.addCleanup(f.close) # teardown will close it
 ...

--
Philip Jenvey