Code review comment for lp:~gz/bzr/cleanup_testcases_by_collection_613247

Revision history for this message
Martin Packman (gz) wrote :

> I'm not worried about the references to test cases in errors/failures
> lists : they are a benefit (and the __dict__ stripping was a _REAL_
> pain there in the past).

Indeed that mostly won't be an issue (and can sometimes be useful), my one worry is the occasional breaks-everything rev will then go back to swapping my machine to death. That's why the current implementation still wipes all uncollected tests, but I'm okay with the idea of removing that once everything else is sorted.

A few things I forgot to mention in the initial review comment.

The lock decorators now use this horribly obnoxious pattern:

    self.lock_read()
    try:
        result = unbound(self, *args, **kwargs)
    except:
        import sys
        exc_info = sys.exc_info()
        try:
            self.unlock()
        finally:
            try:
                raise exc_info[0], exc_info[1], exc_info[2]
            finally:
                del exc_info
    else:
        self.unlock()
        return result

If anyone can think of a sane way of spelling that, please say.

Cycles needing to be avoided will have to be documented if we go with this, and can be annoying to understand without decent knowledge of python internals. I've been using a rough reference tracking function to fix things, but it's not worth landing. Is there any package that can help contributors diagnose things like this?

Would there be any benefit in running all tests with gc disabled by default, and only enabling it for those that explicitly require it?

Is there a better way of telling if the test you just ran failed other than comparing failure counts on the result object?

« Back to merge proposal