Bazaar on IronPython

[Martin Pool]

2009/6/30 Martin (gzlist) <gzlist at googlemail.com>:
> On 30/06/2009, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>>
>> Agreed.  Deliberately confusing the terminology, even with good
>> intentions, won't help do that (although in this case it probably
>> doesn't hurt too much).
>
> I have no desire to chase down a rabbit hole on this, but feel free to
> mentally swap out "GC" in the sentence you objected to for "the
> optional garbage collector in the python `gc` module" or some other
> clearer phrasing. Just wanted to name the difference between Works and
> Does Not Work when both implementations have collectors that will
> clean up file handles.

Let's block off the rabbit hole related to terminology, as we all know
what is meant.

> The point being that I'm not sure how worthwhile it is arguing that
> "relying on garbage collection" is a bad thing when: everybody does
> it, it's simple, and it works. When actual bugs related to object
> lifetimes are fixed it's a good thing (the locks cleanup was a big
> improvement, and there are still various issues that need resolving),
> but

It doesn't work in general, for the reasons alluded to earlier in this
thread.  There have been multiple patches to fix bugs or test failures
by adding explicit finalization.

I also agree that

> littering tests with try/finally doesn't seem a good use of mental
> energy.

In general we can be a bit more lax in tests as long as it does not
cause them to fail (or to falsely pass but that's unlikely.)

You'd have to question too why littering multiple tests with finally
blocks is necessary.  We have methods like build_tree_contents and
should be calling that rather than having many tests duplicate it.
There is also addCleanup.

Do you have a more specific case maybe?

-- 
Martin <http://launchpad.net/~mbp/>