Bazaar on IronPython

[Stephen J. Turnbull]

Martin (gzlist) writes:

 > feel free to mentally swap out "GC" in the sentence you objected to

*sigh*  You're the one who *deliberately* introduced an incorrect
distinction.  I am asking *you*, please, swap out the wrong terms and
use correct ones from now on.

 > 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.

I thought the point was that it *doesn't* work?  An application like
bzr can open a *lot* of files in a short period of time, and if those
handles don't get cleaned up, you can get starved for them.

Just because that doesn't happen in tests doesn't mean that it's a
good idea for bzr developers to get in the habit of just opening a few
files and not worrying about it.  Tests are code, too, and they make
up a significant fraction of the delivered product, even those most
users will never ever run them.  As you point out, there have been a
number of performance problems and outright bugs that have arisen
because people haven't worried about resource usage.

I've seen a post (on emacs-devel) recently where the short release
cycle was cited as evidence of lack of QA in the Bazaar development
process.  I really don't see how to answer that except by pointing to
a very high quality test suite.

 > 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 littering tests with
 > try/finally doesn't seem a good use of mental energy.

That's certainly true.  IMO the right way to address it is via
improving the test scaffolding if that is where the files are being
opened, not by assuming it won't hurt.