[Python-Dev] Gradual migration

Paul Prescod paul@prescod.net
Tue, 24 Oct 2000 09:30:17 -0700


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