Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 411: Provisional packages in the Python standardlibrary
Eli Benderskyeliben at gmail.com
Fri Feb 10 15:06:15 CET 2012
Hi all,Following the intensive and fruitful discussion of the (now rejected)PEP 408 (http://mail.python.org/pipermail/python-dev/2012-January/115850.html),we've drafted PEP 411 to summarize the conclusions with regards to theprocess of marking packages provisional. Note that this is aninformational PEP, and that for the sake of completeness it duplicatessome of the contents of PEP 408.It is pasted below, as well as online athttp://www.python.org/dev/peps/pep-0411/.Comments are welcome.Eli------------------------------------------------PEP: 411Title: Provisional packages in the Python standard libraryVersion: $Revision$Last-Modified: $Date$Author: Nick Coghlan <ncoghlan at gmail.com>, Eli Bendersky <eliben at gmail.com>Status: DraftType: InformationalContent-Type: text/x-rstCreated: 2012-02-10Python-Version: 3.3Post-History: 2012-02-10Abstract========The process of including a new package into the Python standard library ishindered by the API lock-in and promise of backward compatibility implied bya package being formally part of Python. This PEP describes a methodologyfor marking a standard library package "provisional" for the period of a singleminor release. A provisional package may have its API modified prior to"graduating" into a "stable" state. On one hand, this state provides thepackage with the benefits of being formally part of the Python distribution.On the other hand, the core development team explicitly states that no promisesare made with regards to the the stability of the package's API, which maychange for the next release. While it is considered an unlikely outcome,such packages may even be removed from the standard library without adeprecation period if the concerns regarding their API or maintenante provewell-founded.Proposal - a documented provisional state=========================================Whenever the Python core development team decides that a new package should beincluded into the standard library, but isn't entirely sure about whether thepackage'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 entirelyfrom the Python source tree. If the package ends up graduating into thestable state after being provisional for a minor release, its API may bechanged according to accumulated feedback. The core development teamexplicitly makes no guarantees about API stability and backward compatibilityof provisional packages.Marking a package provisional-----------------------------A package will be marked provisional by including the following paragraph asa note at the top of its documentation page: The <X> package has been included in the standard library on a provisional basis. While major changes are not anticipated, as long as this notice remains in place, backwards incompatible changes are permitted if deemed necessary by the standard library developers. Such changes will not be made gratuitously - they will occur only if 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 impliesremoving this note from its documentation page.Which packages should go through the provisional state------------------------------------------------------We expect most packages proposed for addition into the Python standard libraryto go through a minor 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 developmentcommunity.In any case, packages that are proposed to be added to the standard library,whether via the provisional state or directly, must fulfill the acceptanceconditions set by PEP 2.Criteria for "graduation"-------------------------In principle, most provisional packages should eventually graduate to thestable standard library. Some reasons for not graduating are:* 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.Essentially, the decision will be made by the core developers on a per-casebasis. The point to emphasize here is that a packages's inclusion in thestandard library as "provisional" in some release does not guarantee it willcontinue being part of Python in the next release.Rationale=========Benefits for the core development team--------------------------------------Currently, the core developers are really reluctant to add new interfaces tothe standard library. This is because as soon as they're published in arelease, API design mistakes get locked in due to backward compatibilityconcerns.By gating all major API additions through some kind of a provisional mechanismfor a full release, we get one full release cycle of community feedbackbefore we lock in the APIs with our standard backward compatibility guarantee.We can also start integrating provisional packages with the rest of the standardlibrary early, so long as we make it clear to packagers that the provisionalpackages should not be considered optional. The only difference betweenprovisional APIs and the rest of the standard library is that provisional APIsare explicitly exempted from the usual backward compatibility guarantees.Benefits for end users----------------------For future end users, the broadest benefit lies in a better "out-of-the-box"experience - rather than being told "oh, the standard library tools for task Xare horrible, download this 3rd party library instead", those superior toolsare more likely to be just be an import away.For environments where developers are required to conduct due diligence ontheir upstream dependencies (severely harming the cost-effectiveness of, oreven ruling out entirely, much of the material on PyPI), the key benefit liesin ensuring that all packages in the provisional state are clearly underpython-dev's aegis from at least the following perspectives:* Licensing: Redistributed by the PSF under a Contributor Licensing Agreement.* Documentation: The documentation of the package is published and organized via the standard Python documentation tools (i.e. ReST source, output generated with Sphinx and published onhttp://docs.python.org).* Testing: The package test suites are run on the python.org buildbot fleet and results published viahttp://www.python.org/dev/buildbot.* Issue management: Bugs and feature requests are handled onhttp://bugs.python.org* Source control: The master repository for the software is published onhttp://hg.python.org.Candidates for provisional inclusion into the standard library==============================================================For Python 3.3, there are a number of clear current candidates:* ``regex`` (http://pypi.python.org/pypi/regex) - approved by Guido [#]_.* ``daemon`` (PEP 3143)* ``ipaddr`` (PEP 3144)Other possible future use cases include:* Improved HTTP modules (e.g. ``requests``)* HTML 5 parsing support (e.g. ``html5lib``)* Improved URL/URI/IRI parsing* A standard image API (PEP 368)* Encapsulation of the import state (PEP 368)* Standard event loop API (PEP 3153)* A binary version of WSGI for Python 3 (e.g. PEP 444)* Generic function support (e.g. ``simplegeneric``)Rejected alternatives and variations====================================See PEP 408.References==========.. [#]http://mail.python.org/pipermail/python-dev/2012-January/115962.htmlCopyright=========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:
More information about the Python-Devmailing list
[8]ページ先頭