Benjamin Peterson wrote: > Backwards compatibility seems to be an issue that arises a lot here. I > think we all have an idea of it is, but we need some hard place to > point to. So here's my attempt: > Should this PEP include a note about features which require new syntax, particularly new keywords? The policy (AFAICT) is that if new keywords are created they are enabled with a future import (with a warning?) in the version they are introduced and then enabled by default in the next version. All the best, Michael Foord > > PEP: 387 > Title: Backwards Compatibility Policy > Version: $Revision$ > Last-Modified: $Date$ > Author: Benjamin Peterson <benjamin at python.org> > Status: Draft > Type: Process > Content-Type: text/x-rst > Created: 18-Jun-2009 > > > Abstract > ======== > > This PEP outlines Python's backwards compatibility policy. > > > Rationale > ========= > > As one of the most used programming languages today [#tiobe]_, the Python core > language and its standard library play a critcal role in thousands of > applications and libraries. This is fantastic; it is probably one of a language > designer's most wishful dreams. However, it means the development team must be > very careful not to break this existing 3rd party code with new releases. > > > Backwards Compatibility Rules > ============================= > > This policy applys to all public APIs. These include the C-API, the standard > library, and the core language including syntax and operation as defined by the > reference manual. > > This is the basic policy for backwards compatibility: > > * The behavior of an API *must* not change between any two consecutive releases. > > * A feature cannot be removed without notice between any two consecutive > releases. > > * Addition of a feature which breaks 3rd party libraries or applications should > have a large benefit to breakage ratio, and/or the incompatibility should be > trival to fix in broken code. > > > Making Incompatible Changes > =========================== > > It's a fact: design mistakes happen. Thus it is important to be able to change > APIs or remove misguided features. This is accomplished through a gradual > process over several releases: > > 1. Discuss the change. Depending on the size of the incompatibility, this could > be on the bug tracker, python-dev, python-list, or the appropriate SIG. A > PEP or similar document may be written. Hopefully users of the affected API > will pipe up to comment. > > 2. Add a warning [#warnings_]_. If behavior is changing, a the API may gain a > new function or method to perform the new behavior; old usage should raise > the warning. If an API is being removed, simply warn whenever it is entered. > DeprecationWarning is the usual warning category to use, but > PendingDeprecationWarning may be used in special cases were the old and new > versions of the API will coexist for many releases. > > 3. Wait for a release. > > 4. See if there's any feedback. Users not involved in the original discussions > may comment now after seeing the warning. Perhaps reconsider. > > 5. The behavior change or feature removal may now be made default or permanent > in the next release. Remove the old version and warning. > > > References > ========== > > .. [#tiobe] TIOBE Programming Community Index > > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html > > .. [#warnings] The warnings module > > http://docs.python.org/library/warnings.html > > > Copyright > ========= > > This document has been placed in the public domain. > > > > .. > Local Variables: > mode: indented-text > indent-tabs-mode: nil > sentence-end-double-space: t > fill-column: 70 > coding: utf-8 > End: > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
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