From: "Guido van Rossum" <guido at python.org> > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4