[Python-checkins] peps: fixes and cleanups

Fri Feb 10 06:15:01 CET 2012

http://hg.python.org/peps/rev/e39ae2497e70
changeset: 4043:e39ae2497e70
user: Eli Bendersky <eliben at gmail.com>
date: Fri Feb 10 07:14:46 2012 +0200
summary:
 fixes and cleanups
files:
 pep-0411.txt | 13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/pep-0411.txt b/pep-0411.txt
--- a/pep-0411.txt
+++ b/pep-0411.txt
@@ -35,8 +35,8 @@
 
 Whenever the Python core development team decides that a new package should be
 included into the standard library, but isn't entirely sure about whether the
-package's API is optimal, the package can be included and placed in a special
-"provisional" state.
+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
 "stable" state in the standard library, or be rejected and removed entirely
@@ -46,6 +46,7 @@
 explicitly makes no guarantees about API stability and backward compatibility
 of provisional packages.
 
+
 Marking a package provisional
 -----------------------------
 
@@ -60,6 +61,10 @@
 serious API flaws are uncovered that were missed prior to inclusion of
 the package.
 
+Moving a package from the provisional to the stable state simply implies
+removing this note from its documentation page.
+
+
 Which packages should go through the provisional state
 ------------------------------------------------------
 
@@ -82,7 +87,7 @@
 
 * The package may prove to be unstable or fragile, without sufficient developer
 support to maintain it.
-* A much better alternative package may be found during the preview release
+* A much better alternative package may be found during the preview release.
 
 Essentially, the decision will be made by the core developers on a per-case
 basis. The point to emphasize here is that a packages's inclusion in the
@@ -122,7 +127,7 @@
 For environments where developers are required to conduct due diligence on
 their upstream dependencies (severely harming the cost-effectiveness of, or
 even ruling out entirely, much of the material on PyPI), the key benefit lies
-in ensuring that all modules in the provisional state are clearly under
+in ensuring that all packages in the provisional state are clearly under
 python-dev's aegis from at least the following perspectives:
 
 * Licensing: Redistributed by the PSF under a Contributor Licensing Agreement.
-- 
Repository URL: http://hg.python.org/peps
