From: "Guido van Rossum"
On the one hand I understand that those folks want a stable target. On the other hand I think they would prefer to find out sooner rather than later they're using stuff they shouldn't be using any more. It's a delicate balance for sure, and I certainly don't want to open the floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I really don't believe that the strictest interpretation of "no new features" will benefit us for 3.0.1. Perhaps we should decide when to go back to a more strict interpretation of the rules based on the uptake of Python 3 compared to Python 2.
That seems like a smart choice to me. Make the fixups as early as possible, before there has been significant uptake. Am reminded of a cautionary tale from The Art of Unix Programming http://www.faqs.org/docs/artu/ch15s04.html#id2986550 : """ No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the interpretation of a makefile can change drastically on the basis of invisible differences in whitespace. "Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history." -- Stuart Feldman """ Raymond