Guido van Rossum wrote:
...
I think the proper approach is to start a separate migration process for each of these proposed changes.
I agree. As a more concrete extension to my last email, I propose the following doctrine: """ No major documented feature should be removed or have changed semantics in Python 3000 or any other new version of Python until users have had a year (preferably MORE!) of upgrade time. Upgrade time entails the following parts: 1. the released Python version has a new recommended way to accomplish the task in a manner that will remain available in the "breakage version" e.g. a div() function that people can use for a few years while the semantics of "/" are in transition. 2. the mechanism/syntax that will be removed is formally deprecated. The documentation would say, e.g. "You should not use '/' for now. It is changing semantics in the future." 3. the released Python version sports a runtime warning to tell users that the mechanism/syntax is going away. "CompatibilityError: Future versions of Python will have different semantics for the '/' operator. Please use div() instead." The actual "right" amount of upgrade time depends on the extent of the breakage and its ease of detection. """ I can PEP this if people agree. I think that the user community would appreciate our effort to promise not to break code suddenly and capriciously. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html