> 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. Go for it. I have little bandwidth to think about this deeply, but what you're proposing here sounds like a good approach. Certainly it will make it easier if I can point to this PEP when I get the next FUD email about "should I bother to learn Python 2.0 when Py3K is going to be all different?"... --Guido van Rossum (home page: http://www.python.org/~guido/)
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