Other than the misspelling of "maintenante" instead of "maintenance", LGTM.<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 09:06, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Following the intensive and fruitful discussion of the (now rejected)<br>
PEP 408 (<a href="http://mail.python.org/pipermail/python-dev/2012-January/115850.html" target="_blank">http://mail.python.org/pipermail/python-dev/2012-January/115850.html</a>),<br>
we've drafted PEP 411 to summarize the conclusions with regards to the<br>
process of marking packages provisional. Note that this is an<br>
informational PEP, and that for the sake of completeness it duplicates<br>
some of the contents of PEP 408.<br>
<br>
It is pasted below, as well as online at<br>
<a href="http://www.python.org/dev/peps/pep-0411/" target="_blank">http://www.python.org/dev/peps/pep-0411/</a>.<br>
<br>
Comments are welcome.<br>
<br>
Eli<br>
<br>
------------------------------------------------<br>
<br>
<br>
PEP: 411<br>
Title: Provisional packages in the Python standard library<br>
Version: $Revision$<br>
Last-Modified: $Date$<br>
Author: Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>>,<br>
Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>><br>
Status: Draft<br>
Type: Informational<br>
Content-Type: text/x-rst<br>
Created: 2012年02月10日<br>
Python-Version: 3.3<br>
Post-History: 2012年02月10日<br>
<br>
<br>
Abstract<br>
========<br>
<br>
The process of including a new package into the Python standard library is<br>
hindered by the API lock-in and promise of backward compatibility implied by<br>
a package being formally part of Python. This PEP describes a methodology<br>
for marking a standard library package "provisional" for the period of a single<br>
minor release. A provisional package may have its API modified prior to<br>
"graduating" into a "stable" state. On one hand, this state provides the<br>
package with the benefits of being formally part of the Python distribution.<br>
On the other hand, the core development team explicitly states that no promises<br>
are made with regards to the the stability of the package's API, which may<br>
change for the next release. While it is considered an unlikely outcome,<br>
such packages may even be removed from the standard library without a<br>
deprecation period if the concerns regarding their API or maintenante prove<br>
well-founded.<br>
<br>
<br>
Proposal - a documented provisional state<br>
=========================================<br>
<br>
Whenever the Python core development team decides that a new package should be<br>
included into the standard library, but isn't entirely sure about whether the<br>
package's API is optimal, the package can be included and marked as<br>
"provisional".<br>
<br>
In the next minor release, the package may either be "graduated" into a normal<br>
"stable" state in the standard library, or be rejected and removed entirely<br>
from the Python source tree. If the package ends up graduating into the<br>
stable state after being provisional for a minor release, its API may be<br>
changed according to accumulated feedback. The core development team<br>
explicitly makes no guarantees about API stability and backward compatibility<br>
of provisional packages.<br>
<br>
<br>
Marking a package provisional<br>
-----------------------------<br>
<br>
A package will be marked provisional by including the following paragraph as<br>
a note at the top of its documentation page:<br>
<br>
The <X> package has been included in the standard library on a<br>
provisional basis. While major changes are not anticipated, as long as<br>
this notice remains in place, backwards incompatible changes are<br>
permitted if deemed necessary by the standard library developers. Such<br>
changes will not be made gratuitously - they will occur only if<br>
serious API flaws are uncovered that were missed prior to inclusion of<br>
the package.<br>
<br>
Moving a package from the provisional to the stable state simply implies<br>
removing this note from its documentation page.<br>
<br>
<br>
Which packages should go through the provisional state<br>
------------------------------------------------------<br>
<br>
We expect most packages proposed for addition into the Python standard library<br>
to go through a minor release in the provisional state. There may, however,<br>
be some exceptions, such as packages that use a pre-defined API (for example<br>
``lzma``, which generally follows the API of the existing ``bz2`` package),<br>
or packages with an API that has wide acceptance in the Python development<br>
community.<br>
<br>
In any case, packages that are proposed to be added to the standard library,<br>
whether via the provisional state or directly, must fulfill the acceptance<br>
conditions set by PEP 2.<br>
<br>
Criteria for "graduation"<br>
-------------------------<br>
<br>
In principle, most provisional packages should eventually graduate to the<br>
stable standard library. Some reasons for not graduating are:<br>
<br>
* The package may prove to be unstable or fragile, without sufficient developer<br>
support to maintain it.<br>
* A much better alternative package may be found during the preview release.<br>
<br>
Essentially, the decision will be made by the core developers on a per-case<br>
basis. The point to emphasize here is that a packages's inclusion in the<br>
standard library as "provisional" in some release does not guarantee it will<br>
continue being part of Python in the next release.<br>
<br>
<br>
Rationale<br>
=========<br>
<br>
Benefits for the core development team<br>
--------------------------------------<br>
<br>
Currently, the core developers are really reluctant to add new interfaces to<br>
the standard library. This is because as soon as they're published in a<br>
release, API design mistakes get locked in due to backward compatibility<br>
concerns.<br>
<br>
By gating all major API additions through some kind of a provisional mechanism<br>
for a full release, we get one full release cycle of community feedback<br>
before we lock in the APIs with our standard backward compatibility guarantee.<br>
<br>
We can also start integrating provisional packages with the rest of the standard<br>
library early, so long as we make it clear to packagers that the provisional<br>
packages should not be considered optional. The only difference between<br>
provisional APIs and the rest of the standard library is that provisional APIs<br>
are explicitly exempted from the usual backward compatibility guarantees.<br>
<br>
Benefits for end users<br>
----------------------<br>
<br>
For future end users, the broadest benefit lies in a better "out-of-the-box"<br>
experience - rather than being told "oh, the standard library tools for task X<br>
are horrible, download this 3rd party library instead", those superior tools<br>
are more likely to be just be an import away.<br>
<br>
For environments where developers are required to conduct due diligence on<br>
their upstream dependencies (severely harming the cost-effectiveness of, or<br>
even ruling out entirely, much of the material on PyPI), the key benefit lies<br>
in ensuring that all packages in the provisional state are clearly under<br>
python-dev's aegis from at least the following perspectives:<br>
<br>
* Licensing: Redistributed by the PSF under a Contributor Licensing Agreement.<br>
* Documentation: The documentation of the package is published and organized via<br>
the standard Python documentation tools (i.e. ReST source, output generated<br>
with Sphinx and published on <a href="http://docs.python.org" target="_blank">http://docs.python.org</a>).<br>
* Testing: The package test suites are run on the <a href="http://python.org" target="_blank">python.org</a> buildbot fleet<br>
and results published via <a href="http://www.python.org/dev/buildbot" target="_blank">http://www.python.org/dev/buildbot</a>.<br>
* Issue management: Bugs and feature requests are handled on<br>
<a href="http://bugs.python.org" target="_blank">http://bugs.python.org</a><br>
* Source control: The master repository for the software is published<br>
on <a href="http://hg.python.org" target="_blank">http://hg.python.org</a>.<br>
<br>
<br>
Candidates for provisional inclusion into the standard library<br>
==============================================================<br>
<br>
For Python 3.3, there are a number of clear current candidates:<br>
<br>
* ``regex`` (<a href="http://pypi.python.org/pypi/regex" target="_blank">http://pypi.python.org/pypi/regex</a>) - approved by Guido [#]_.<br>
* ``daemon`` (PEP 3143)<br>
* ``ipaddr`` (PEP 3144)<br>
<br>
Other possible future use cases include:<br>
<br>
* Improved HTTP modules (e.g. ``requests``)<br>
* HTML 5 parsing support (e.g. ``html5lib``)<br>
* Improved URL/URI/IRI parsing<br>
* A standard image API (PEP 368)<br>
* Encapsulation of the import state (PEP 368)<br>
* Standard event loop API (PEP 3153)<br>
* A binary version of WSGI for Python 3 (e.g. PEP 444)<br>
* Generic function support (e.g. ``simplegeneric``)<br>
<br>
<br>
Rejected alternatives and variations<br>
====================================<br>
<br>
See PEP 408.<br>
<br>
<br>
References<br>
==========<br>
<br>
.. [#] <a href="http://mail.python.org/pipermail/python-dev/2012-January/115962.html" target="_blank">http://mail.python.org/pipermail/python-dev/2012-January/115962.html</a><br>
<br>
Copyright<br>
=========<br>
<br>
This document has been placed in the public domain.<br>
<br>
<br>
..<br>
Local Variables:<br>
mode: indented-text<br>
indent-tabs-mode: nil<br>
sentence-end-double-space: t<br>
fill-column: 70<br>
coding: utf-8<br>
End:<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">http://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div><br>