PEP 2: 新しいモジュールの追加手続き ==================================== 原文: http://www.python.org/dev/peps/pep-0002/ +---------------+----------------------------------------------+ | PEP | 2 | +---------------+----------------------------------------------+ | Title | Procedure for Adding New Modules | +---------------+----------------------------------------------+ | Version | 56077 | +---------------+----------------------------------------------+ | Last-Modified | 2007-06-22 20:50:54 +0200 (Fri, 22 Jun 2007) | +---------------+----------------------------------------------+ | Author | Martijn Faassen | +---------------+----------------------------------------------+ | Status | Active | +---------------+----------------------------------------------+ | Type | Process | +---------------+----------------------------------------------+ | Created | 07-Jul-2001 | +---------------+----------------------------------------------+ | Post-History | 07-Jul-2001, 09-Mar-2002 | +---------------+----------------------------------------------+ イントロダクション -------------------- .. The Python Standard Library contributes significantly to Python's success. The language comes with "batteries included", so it is easy for people to become productive with just the standard library alone. It is therefore important that this library grows with the language, and that such growth is supported and encouraged. Python標準ライブラリは、Pythonの成功に多大な寄与をしました。"バッテリー 内蔵"の言語は、標準ライブラリだけで人々を生産的にしました。そのため、 このライブラリが言語と共に発展し、そして、その発展が励みになることが重 要となるのです。 .. Many contributions to the library are not created by core developers but by people from the Python community who are experts in their particular field. Furthermore, community members are also the users of the standard library, applying it in a great diversity of settings. This makes the community well equipped to detect and report gaps in the library; things that are missing but should be added. このライブラリは、主要な開発者だけでなく、Pythonコミュニティでの各分野で の専門家からも多大な寄与さらに、コミュニティのメンバーはこの標準ライブラ リのユーザでもあり、偉大なほど多様な設定を適用してくれました。これはコミュ ニティにライブラリ中のバグを発見し、報告する能力をもたらしています。失わ れたものごとは、付け加えられるのです(訳注:定型句？)。 .. New functionality is commonly added to the library in the form of new modules. This PEP will describe the procedure for the _addition_ of new modules. PEP 4 deals with procedures for deprecation of modules; the _removal_ of old and unused modules from the standard library. Finally there is also the issue of _changing_ existing modules to make the picture of library evolution complete. PEP 3 and PEP 5 give some guidelines on this. The continued maintenance of existing modules is an integral part of the decision on whether to add a new module to the standard library. Therefore, this PEP also introduces concepts (integrators, maintainers) relevant to the maintenance issue. 通常、新しい機能は新しいモジュールの形となってライブラリに付け加えられま す。このPEPは、新しいモジュールを **追加** する手続きについて述べています。 また、古い使われていないモジュールを標準ライブラリから **取り除く** 手続 きも含まれています。最後に、ライブラリを完全なものにするために、既存のモ ジュールを **変更** することに関しても述べられています。PEP 3とPEP 5はこ の手続きに関するガイドラインを提供しています。既存のモジュールに対する継 続的なメンテナンスは、新しいモジュールを付け加える決定に関わらず、完全な ものになるために必要な部分です。そのため、このPEPはメンテナンスの問題に関 する適切なコンセプト(インテグレータ、メンテナ)を紹介します。 .. Integrators --------------- インテグレータ(訳注: 適切な訳はなんだろう) ------------------------------------------ .. The integrators are a group of people with the following responsibilities: インテグレータは以下の責任を持つ人々の集まりです。 .. - They determine if a proposed contribution should become part of the standard library. - 提案が標準ライブラリの一部分になるべきかを決定する .. - They integrate accepted contributions into the standard library. - 標準ライブラリへの貢献を受理する .. - They produce standard library releases. - 標準ライブラリをリリースする .. This group of people shall be PythonLabs, led by Guido. - このグループは、Guidoによって率いられているPythonLabsの人々である .. Maintainer(s) --------------- メンテナ --------------- .. All contributions to the standard library need one or more maintainers. This can be an individual, but it is frequently a group of people such as the XML-SIG. Groups may subdivide maintenance tasks among themselves. One ore more maintainers shall be the _head maintainer_ (usually this is also the main developer). Head maintainers are convenient people the integrators can address if they want to resolve specific issues, such as the ones detailed later in this document. 標準ライブラリへの全ての貢献は一人以上のメンテナを必要とします。これは XML-SIGのような独立した、しかし継続的な人々の集まりです。グループはメンテ ナンスの仕事に応じて細分化されます。一人以上のメンテナが **メンテナ長** (Head maintainer)となります(この人は大体の場合において、主要開発者である)。 メンテナ長は、インテグレータがこの文書で後に述べるような特定の問題を解決 してほしいと指し示しやすい人々です。 .. Developers(s) --------------- 開発者 --------------- .. Contributions to the standard library have been developed by one or more developers. The initial maintainers are the original developers unless there are special circumstances (which should be detailed in the PEP proposing the contribution). 標準ライブラリへの貢献は、一人以上の開発者によって開発されます。(PEPの貢献 への誘いにて述べられるような)特別な事情がない限り、最初のメンテナは元々の 開発者です。 .. Acceptance Procedure 受理の手続き --------------- .. When developers wish to have a contribution accepted into the standard library, they will first form a group of maintainers (normally initially consisting of themselves). 開発者が貢献を標準ライブラリに受け入れて欲しいと願ったとき、最初にメンテ ナのグループを作ってください(通常最初は彼ら自身で構成されます)。 .. Then, this group shall produce a PEP called a library PEP. A library PEP is a special form of standards track PEP. The library PEP gives an overview of the proposed contribution, along with the proposed contribution as the reference implementation. This PEP should also contain a motivation on why this contribution should be part of the standard library. それから、そのグループはライブラリPEPと呼ばれるPEPの手続きを進めます。ラ イブラリPEPはスタンダードトラックのPEPのうちの特別なPEPです。このライブラ リPEPは提案された貢献の概要と、参照実装を提供することになります。このPEP はなぜこの貢献が標準ライブラリの一部とならなければならないのかという理由 を含む必要があります。 .. One or more maintainers shall step forward as PEP champion (the people listed in the Author field are the champions). The PEP champion(s) shall be the initial head maintainer(s). 一人以上のメンテナがPEPチャンピオン(著者に挙がっている人々がチャンピオン です)として、手続きを進める必要があります。このPEPチャンピオン(達)が、最 初のメンテナ長です。 .. As described in PEP 1, a standards track PEP should consist of a design document and a reference implementation. The library PEP differs from a normal standard track PEP in that the reference implementation should in this case always already have been written before the PEP is to be reviewed for inclusion by the integrators and to be commented upon by the community; the reference implementation _is_ the proposed contribution. PEP 1で述べられた通り、スタンダードトラックPEPは設計と参照実装を含まなけ ればなりません。ライブラリPEPは通常のスタンダードトラックPEPと異なり、 常にPEPが書かれるより前に参照実装がなくてはなりません。また、この参照実装 はインテグレータによってレビューされ、コミュニティからコメントを受け付け なくてはなりません。参照実装 **こそが** 提案されている貢献なのです。 .. This different requirement exists for the following reasons: この異なる要求事項は、以下の理由によって求められています。 .. - The integrators can only properly evaluate a contribution to the standard library when there is source code and documentation to look at; i.e. the reference implementation is always necessary to aid people in studying the PEP. ソースコードと文章を調べるときに、インテグレータこそが標準ライブラリへの 貢献を正しく判断できるからです。すなわち、参照実装はPEPを勉強している人々 に取って常に必要なのです。(訳注: 自信無) .. - Even rejected contributions will be useful outside the standard library, so there will a lower risk of waste of effort by the developers. 貢献が拒否されたとしても、標準ライブラリ以外にとっては有益な場合がありま す。そのため、開発者の努力を無駄にするリスクを低くします。 .. - It will impress the integrators of the seriousness of contribution and will help guard them against having to evaluate too many frivolous proposals. インテグレータの真剣な貢献が良い印象を与え、不真面目な提案を数多く検討し なければならない事態を防ぎます。 .. Once the library PEP has been submitted for review, the integrators will then evaluate it. The PEP will follow the normal PEP work flow as described in PEP 1. If the PEP is accepted, they will work through the head maintainers to make the contribution ready for integration. 一度ライブラリPEPがレビューに申請されると、インテグレータはそれを評価しま す。PEPはPEP 1で述べられた標準PEPのワークフローに則ります。もしそのPEPが 受理された場合、メンテナ長に回覧され、その貢献を標準ライブラリに統合する 準備にとりかかります。 .. Maintenance Procedure メンテナンスの手続き -------------------- .. After a contribution has been accepted, the job is not over for both integrators and maintainers. The integrators will forward any bug reports in the standard library to the appropriate head maintainers. 貢献が受理されれば、インテグレータとメンテナの両方にとってその仕事が終わ り、というわけではありません。インテグレータはインテグレータは標準ライブ ラリ中のどんなバグ報告も、適切なメンテナ長に転送します。 .. Before the feature freeze preparing for a release of the standard library, the integrators will check with the head maintainers for all contributions, to see if there are any updates to be included in the next release. The integrators will evaluate any such updates for issues like backwards compatibility and may require PEPs if the changes are deemed to be large. 標準ライブラリのリリースに備えて機能を凍結する準備をする前に、インテグレー タはメンテナ長と一緒に、次のリリースに含む更新がないか全ての貢献をチェッ クします。インテグレータはその更新を、後方互換性が保たれてるかなどを評価 します。また、更新が大きすぎる場合はPEPが必要となる場合もあります .. The head maintainers should take an active role in keeping up to date with the Python development process. If a head maintainer is unable to function in this way, he or she should announce the intention to step down to the integrators and the rest of the maintainers, so that a replacement can step forward. The integrators should at all times be capable of reaching the head maintainers by email. メンテナ長はPythonの開発プロセスを最新に保つために活発な役目を担う必要が あります。もしメンテナ長がその役目をできないばあい、インテグレータに降格 するというアナウンスをする必要があります。これにより、メンテナの残りの人 が昇格することになります。インテグレータはメンテナ長とE-メールで連絡を取 り合えるようにしておく必要があります。 .. In the case where no head maintainer can be found (possibly because there are no maintainers left), the integrators will issue a call to the community at large asking for new maintainers to step forward. If no one does, the integrators can decide to declare the contribution deprecated as described in PEP 4. (もうメンテナがいないなどによって)メンテナ長が見つからない場合は、インテ グレータは昇格するための新しいメンテナをコミュニティから広く募集します。 もしも誰もいない場合、インテグレータはPEP 4で述べられているように、その 貢献を廃止宣言する可能性があります。 .. Open Issues ------------- 未解決な問題 ------------- .. There needs to be some procedure so that the integrators can always reach the maintainers (or at least the head maintainers). This could be accomplished by a mailing list to which all head maintainers should be subscribed (this could be python-dev). Another possibility, which may be useful in any case, is the maintenance of a list similar to that of the list of PEPs which lists all the contributions and their head maintainers with contact info. This could in fact be part of the list of the PEPs, as a new contribution requires a PEP. But since the authors/owners of a PEP introducing a new module may eventually be different from those who maintain it, this wouldn't resolve all issues yet. インテグレータはメンテナ(最低限メンテナ長と)と常に連絡をとれるような方法 が必要です。そのためには、全てのメンテナ長がメーリングリスト(python-devが 適当か)を購読することなどが方法として挙げられます。他の可能性としては、 PEPリストと同じようなリストを全ての貢献について作成し、それにメンテナ長の 連絡先も併記しておくのです。PEPを要求する新しい貢献には、PEPリストの一部 として実際なっています(訳注: 自信無)。しかし、新しいモジュールを導入した PEPの著者と管理者とが別になる事態が起きてしまいます。 .. This relates to all the technical issues; check-in privileges, coding style requirements, documentation requirements, test suite requirements. These are preferably part of another PEP. この件は、全ての技術的な問題に関連します。チェックイン権限、コーディング スタイルの要求、文書化の要求、テストの要求。これに関しては別のPEPで述べる 方が良いでしょう。 .. Should the current standard library be subdivided among maintainers? Many parts already have (informal) maintainers; it may be good to make this more explicit. 現在の標準ライブラリはメンテナの間で細分化されるべきか？多くの部分にはす でに(非公式の)メンテナがいます。もっと明文化させることがいい考えかもしれ ません。 .. Perhaps there is a better word for 'contribution'; the word 'contribution' may not imply enough that the process (of development and maintenance) does not stop after the contribution is accepted and integrated into the library. '貢献(contribution)'よりもっといい単語があるかもしれません。'貢献'という 言葉はライブラリに統合されたあとも貢献を止めないというその(開発や管理の)プロセスを十分に意味していないかもしれません。 .. Relationship to the mythical Catalog? 関連性とは神話のカタログか？(訳注: 意味がとれない) .. Copyright --------------- 著作権 --------------- .. This document has been placed in the public domain. このドキュメントはパブリック・ドメインに属します。 Local Variables: coding: utf-8 End: