原文: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 |
プログラミング言語の自然な発展形態において、過去のプログラムの振る舞いを変える必要がある場合が時として起こります。このPEPではインストールを主体とするPythonユーザにとって丁寧に変化が起きるように、実装のポリシーを提案します。
このPEPの実装には、追加の正式な警告と他の提案の中で言及されるであろう利便性とを追加しなければなりません。
これらのガイドラインはPythonの将来のバージョンに対して後方互換性の振る舞いを紹介するためのものです。後方互換性をなくすことは、標準のPythonドキュメントがかかれた初期段階からなされている説明を逸脱することです。機能を取り除くことも、同様に振る舞いを変更することとなります。
このPEPは後方互換性があるパーサーのDynamic Loadingなどといった、他の互換性を提供する技術を置き換えたり、前触れとするものではありません。一方、”古いコード”の実行が特別な切り替えやpragmaを要求する場合(訳注: 自信無)、実行したいユーザの観点から、振る舞いを変更することが必要になることも考えられます。その場合、その変更は、以下のガイドラインに従って実装する必要があります。
一般に、これらのガイドラインの実装において、常識が優先されます。例えば”sys.copyright”の変更は、振る舞いを変更し、後方互換性の不備を引き起こします。(訳注: だけど常識で判断して別に問題ない、といいたいんだと思う)
1. PEPで後方互換性の振る舞いを提案します。そのPEPは以下のステップを全部クリアする詳細について述べた後方互換性に関する節を含まなければいけません。
2. 一度PEPが開発項目として受理されたら、取り除かれたり変更されたりすることになる以前の機能を別の方法で実装します。例えば、加算演算子が取り除かれる事が決まったら、新しいバージョンのpythonでは、組み込みの機能として”add()”を実装するかもしれません。
4. parserにユーザに対して廃止されたということを知らせるオプショナルな警告モードを追加します。つまり、異なる振る舞いをする全てのプログラムは将来に渡ってこの警告モードで警告を表示しなければなりません。 コンパイル時の警告は実行時の警告より望ましいです。この警告メッセージは廃止された手法から別の手法へと変更するようにユーザに助言するものであるべきです。
移行したバージョンのリリースと後方互換性がなくなったバージョンのリリースとの間隔は、最低1年の期間を置くべきです。ユーザは最低1年間の自分のプログラムをテストでき、廃止された手法から別の手法へと変更できます。
Local Variables:coding: utf-8End: