[Python-checkins] peps: Address Guido's comments from the pronouncement request on python-dev

[eli.bendersky]

http://hg.python.org/peps/rev/a1bb0a9af63f
changeset:   4151:a1bb0a9af63f
user:        Eli Bendersky <eliben at gmail.com>
date:        Tue Mar 27 05:20:49 2012 +0200
summary:
  Address Guido's comments from the pronouncement request on python-dev

files:
  pep-0411.txt |  11 +++++++----
  1 files changed, 7 insertions(+), 4 deletions(-)


diff --git a/pep-0411.txt b/pep-0411.txt
--- a/pep-0411.txt
+++ b/pep-0411.txt
@@ -19,7 +19,7 @@
 hindered by the API lock-in and promise of backward compatibility implied by
 a package being formally part of Python.  This PEP describes a methodology
 for marking a standard library package "provisional" for the period of a single
-minor release.  A provisional package may have its API modified prior to
+feature release.  A provisional package may have its API modified prior to
 "graduating" into a "stable" state.  On one hand, this state provides the
 package with the benefits of being formally part of the Python distribution.
 On the other hand, the core development team explicitly states that no promises
@@ -38,7 +38,7 @@
 package's API is optimal, the package can be included and marked as
 "provisional".
 
-In the next minor release, the package may either be "graduated" into a normal
+In the next feature release, the package may either be "graduated" into a normal
 "stable" state in the standard library, remain in provisional state, or be
 rejected and removed entirely from the Python source tree.  If the package ends
 up graduating into the stable state after being provisional, its API may
@@ -87,7 +87,7 @@
 ------------------------------------------------------
 
 We expect most packages proposed for addition into the Python standard library
-to go through a minor release in the provisional state. There may, however,
+to go through a feature release in the provisional state. There may, however,
 be some exceptions, such as packages that use a pre-defined API (for example
 ``lzma``, which generally follows the API of the existing ``bz2`` package),
 or packages with an API that has wide acceptance in the Python development
@@ -110,7 +110,10 @@
 Essentially, the decision will be made by the core developers on a per-case
 basis.  The point to emphasize here is that a package's inclusion in the
 standard library as "provisional" in some release does not guarantee it will
-continue being part of Python in the next release.
+continue being part of Python in the next release.  At the same time, the bar
+for making changes in a provisional package is quite high.  We expect that
+most of the API of most provisional packages will be unchanged at graduation.
+Withdrawals are expected to be rare.
 
 
 Rationale

-- 
Repository URL: http://hg.python.org/peps