> Ah, OK, that explains it. This is a reasonable thing to do from a > performance point of view. Thanks for plugging away at this. :) > > (Of course it's too bad we don't have a better way of testing changes. > Oh well.)
If there were volunteer testers, it would be possible to test changes for some period of time. Such testers would have to build themselves a PyPI installation, and then checkout all changes that have been committed (or install them from a tracker where they float around). Alternatively, if somebody contributed a unit test suite, certain problems might get caught. In the specific case, I tested whether PyPI "works" on my local installation, and I apparently didn't not manage to trigger the problem. My guess is that it was originally triggered by some failing concurrent access, which is really hard to test for. Regards, Martin _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
