[Tim] >> In addition, not shown above is that I changed test_wsgiref.py to stop >> a test failure under -O. Given that we're close to the next Python >> release, and test_wsgiref was the only -O test failure, I wasn't going >> to let that stand. I did wait ~30 hours between emailing about the >> problem and fixing it, but I like to whittle down my endless todo list >> too <0.4 wink>.
[Phillip] > Your fix masked one of the *actual* problems, which was that > wsgiref.validate (contributed by Ian Bicking) was also using asserts to > check for validation failures. This required a more extensive fix. (See > my reply to your problem report.) No, I didn't mask that. Two individual tests in test_wsgiref were failing under -O, and I only fixed one of them (testFileWrapper) at the time. In the checkin message for that (rev 46871), I noted that the other failure (test_simple_validation_error) was due to the coding of wsgiref.validate, and also noted that extensive changes would be needed to repair that one. The failure of the test I did repair was solely due to code in test_wsgiref.py. > Your post about the error was on Friday afternoon; I had a corrected > version on Sunday evening, but I couldn't check it in because nobody told > me about any of the "ordinary everyday maintenance" they were doing, and I > had to figure out how to merge the now-divergent trees. I'm sorry, but I don't think you can expect to get special email about these never-ending kinds of small changes. It's not realistic. They all show up on the python-checkins list, which you could filter (you are subscribed to that, right?). You could also use the svn command I showed last time to get a list of all checkins that have modified one of your files since the last time you blessed it. I know this is possible, since at one point I had to keep track of random changes to ZODB from copies in umpteen different branches of Zope2 and Zope3. I also know it's a PITA ;-) But AFAIK you have only _one_ "external copy" to keep track of now, and IME the pain grew more like the square of the number of external copies (each pair of external copies effectively had to get compared). > The whitespace changes I expected, since you previously told me about > reindent.py. The other changes I did not expect, since my original message > about the checkin requested that people at least keep me informed of > changes (as does PEP 360), so I thought that people would abide by that or > at least notify me if they found it necessary to make a change to e.g. fix > a test. Well, I don't pay any attention to which files reindent.py changes, so you'll never get special email from me about that. It looked like Brett's checkin was the result of some similarly mechanical "look for code directories that forgot to svn:ignore compiled Python files" process. Neal's PyChecker checkin also touched more than one subproject, and he probably plain forgot that anything with "wsgiref" in its path was supposed to get special treatment. These things simply will happen, and especially in more-or-less mindless cleanup checkins. > Your email about the test problem didn't say you were making any changes. There's also a rule that all tests must pass, and as a release grows close that gets higher priority. As I said, I waited about 30 hours, but got no response and saw no action, so moved it along simply because it needed to be repaired and I was able to make time for it. If you hadn't repaired test_simple_validation_error, I would have had no qualms about hacking in anything to stop that failure too before the release. If we had been "far" away from a release, I wouldn't have done anything here (beyond sending the email). > Regardless of "everyday maintenance", my point was that I understood one > procedure to be in effect, per PEP 360. If nobody's expected to actually > pay any attention to that procedure, there's no point in having the > PEP. Or if "everyday maintenance" is expected to be exempt, the PEP should > reflect that. Since that one is the only realistic outcome I can see, I think the PEP should say so. > Assuming that everybody knows which rules do and don't count is a non-starter > on a project the size of Python. I expect most rules will never be written down, either. This works fine so long as people of good will cooperate with liberal doses of common sense and tolerance. It doesn't work at all when the process gets adversarial. This project's traditional response to that hasn't been to craft ever-more legalistic rules (in part because nobody will volunteer for that), but to give the BDFL the last word on everything. Alas, that shows signs of not scaling well to dozens of active developers either. Short of freezing the code base and dropping support for buggy platforms like Linux ;-), I don't pretend to have a solution. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
