PEP 5: 言語開発のガイドライン ======================================== 原文: http://www.python.org/dev/peps/pep-0005/ +---------------+----------------------------------------------+ | PEP | 5 | +---------------+----------------------------------------------+ | Title | Guidelines for Language Evolution | +---------------+----------------------------------------------+ | Version | 56036 | +---------------+----------------------------------------------+ | Last-Modified | 2007-06-19 06:52:34 +0200 (Tue, 19 Jun 2007) | +---------------+----------------------------------------------+ | Author | paul@prescod.net (Paul Prescod) | +---------------+----------------------------------------------+ | Status | Active | +---------------+----------------------------------------------+ | Type | Process | +---------------+----------------------------------------------+ | Created | 26-Oct-2000 | +---------------+----------------------------------------------+ | Post-History | | +---------------+----------------------------------------------+ .. Abstract ---------- 概要 ---------- .. In the natural evolution of programming languages it is sometimes necessary to make changes that modify the behavior of older programs. This PEP proposes a policy for implementing these changes in a manner respectful of the installed base of Python users. プログラミング言語の自然な発展形態において、過去のプログラムの振る舞いを 変える必要がある場合が時として起こります。このPEPではインストールを主体と するPythonユーザにとって丁寧に変化が起きるように、実装のポリシーを提案し ます。 .. Implementation Details ---------------------- 実装の詳細 --------------- .. Implementation of this PEP requires the addition of a formal warning and deprecation facility that will be described in another proposal. このPEPの実装には、追加の正式な警告と他の提案の中で言及されるであろう利便 性とを追加しなければなりません。 .. Scope ------ 範囲 ----- .. These guidelines apply to future versions of Python that introduce backward-incompatible behavior. Backward incompatible behavior is a major deviation in Python interpretation from an earlier behavior described in the standard Python documentation. Removal of a feature also constitutes a change of behavior. これらのガイドラインはPythonの将来のバージョンに対して後方互換性の振る舞 いを紹介するためのものです。後方互換性をなくすことは、標準のPythonドキュ メントがかかれた初期段階からなされている説明を逸脱することです。機能を取 り除くことも、同様に振る舞いを変更することとなります。 .. This PEP does not replace or preclude other compatibility strategies such as dynamic loading of backwards-compatible parsers. On the other hand, if execution of "old code" requires a special switch or pragma then that is indeed a change of behavior from the point of view of the user and that change should be implemented according to these guidelines. このPEPは後方互換性があるパーサーのDynamic Loadingなどといった、他の互換 性を提供する技術を置き換えたり、前触れとするものではありません。一方、"古 いコード"の実行が特別な切り替えやpragmaを要求する場合(訳注: 自信無)、実行 したいユーザの観点から、振る舞いを変更することが必要になることも考えられ ます。その場合、その変更は、以下のガイドラインに従って実装する必要があり ます。 .. In general, common sense must prevail in the implementation of these guidelines. For instance changing "sys.copyright" does not constitute a backwards-incompatible change of behavior! 一般に、これらのガイドラインの実装において、常識が優先されます。例えば "sys.copyright"の変更は、振る舞いを変更し、後方互換性の不備を引き起こしま す。(訳注: だけど常識で判断して別に問題ない、といいたいんだと思う) .. Steps For Introducing Backwards-Incompatible Features --------------------------------------------------------------- 後方互換性の機能を導入するステップ ------------------------------------ .. 1. Propose backwards-incompatible behavior in a PEP. The PEP must include a section on backwards compatibility that describes in detail a plan to complete the remainder of these steps. 1. PEPで後方互換性の振る舞いを提案します。そのPEPは以下のステップを全部クリ アする詳細について述べた後方互換性に関する節を含まなければいけません。 .. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. For instance if the addition operator were scheduled for removal, a new version of Python could implement an "add()" built-in function. 2. 一度PEPが開発項目として受理されたら、取り除かれたり変更されたりすることに なる以前の機能を別の方法で実装します。例えば、加算演算子が取り除かれる事 が決まったら、新しいバージョンのpythonでは、組み込みの機能として"add()" を実装するかもしれません。 .. 3. Formally deprecate the obsolete construct in the Python documentation. 3. Pythonの文書にて、古い設計を正式に廃止にします。 .. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. In other words, all programs that will behave differently in the future must trigger warnings in this mode. Compile-time warnings are preferable to runtime warnings. The warning messages should steer people from the deprecated construct to the alternative construct. 4. parserにユーザに対して廃止されたということを知らせるオプショナルな警告モー ドを追加します。つまり、異なる振る舞いをする全てのプログラムは将来に渡っ てこの警告モードで警告を表示しなければなりません。 コンパイル時の警告は実 行時の警告より望ましいです。この警告メッセージは廃止された手法から別の手 法へと変更するようにユーザに助言するものであるべきです。 .. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. 移行したバージョンのリリースと後方互換性がなくなったバージョンのリリー スとの間隔は、最低1年の期間を置くべきです。ユーザは最低1年間の自分のプ ログラムをテストでき、廃止された手法から別の手法へと変更できます。 Local Variables: coding: utf-8 End: