From: "Guido van Rossum" <gu...@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
_______________________________________________
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
