PEP 3000
要約
This PEP sets guidelines for Python 3000 development. Ideally, we first agree on the process, and start discussing features only after the process has been decided and specified. In practice, we'll be discussing features and process simultaneously; often the debate about a particular feature will prompt a process discussion.
この PEP は Python 3000 に関する概略を定めています。プロセスについて合意を得てから， 合意を得たものについてのみ機能に関する議論をはじめるのが理想です。 現実的には、機能とプロセスに関する議論は同時に行われることになるはずです。 特定の機能について議論をすることは，プロセスに関する議論を活発にすることが 往々にしてあります。
名前について
Python 3000, Python 3.0 and Py3K are all names for the same thing. The project is called Python 3000, or abbreviated to Py3k. The actual Python release will be referred to as Python 3.0, and that's what "python3.0 -V" will print; the actual file names will use the same naming convention we use for Python 2.x. I don't want to pick a new name for the executable or change the suffix for Python source files.
Python 3000, Python 3.0 および Py3K はすべて同じものを指しています。 このプロジェクトは Python 3000 と呼ばれます。 Py3k と略されることもあります。 実際にリリースされる Python は Python 3.0 と名付けられることでしょう。 "python3.0 -V" というコマンドをタイプすると表示されるのも Python 3.0 となります。 実際の実行ファイル名は，現在 Python 2.x で利用されているものと同じ形式になるでしょう。 実行形式のファイル名に新しい形式を採用したり，Python のソースコードの拡張子を変更 することは私は望んでいません。I don't want to pick a
PEP の番号について
Python 3000 PEPs are numbered starting at PEP 3000. PEPs 3000-3099 are meta-PEPs -- these can be either process or informational PEPs. PEPs 3100-3999 are feature PEPs. PEP 3000 itself (this PEP) is special; it is the meta-PEP for Python 3000 meta-PEPs (IOW it describe the process to define processes). PEP 3100 is also special; it's a laundry list of features that were selected for (hopeful) inclusion in Python 3000 before we started the Python 3000 process for real. PEP 3099, finally, is a list of features that will not change.
Python 3000 の PEP には PEP 3000 から始まる番号をつけます。 PEP 3000 から 3099 はメタ PEP になります。この PEP はプロセスを定義する PEP である場合もありますし， 情報のための PEPであることもあります。 PEP 3100 から 3999 は機能を定義するための PEPです。この PEP 3000 は特別な PEP です。この PEP は， PEP 3000 シリーズのための メタ PEP です (言い方を変えると，この PEP はプロセスを定義するためのプロセスについて定めています)。 PEP 3100 も特別な PEP です。この PEP には， Python 3000 の開発をはじめる前に Python 3000 に ( できるかぎり ) 加えるもののリストを記述しています。 PEP 3099 は変更 * されない * 機能のリストになります。
タイムライン
We need a meta-PEP for the Python 3000 timeline. At this moment, I hope to have a first alpha release out sometime in 2007; it may take another year after that (or more) before the first proper release, named Python 3.0.
Python 3000 のタイムラインに関する メタ PEP が別に必要です。現時点では， 私は 2007 年のうちに最初のアルファバージョンをリリースすることを望んでいます。 Python 3.0 という名前がついたものをリリースするまでには，もう一年かもっと かかるかも知れません
I expect that there will be parallel Python 2.x and 3.x releases for some time; the Python 2.x releases will continue for a longer time than the traditional 2.x.y bugfix releases. Typically, we stop releasing bugfix versions for 2.x once version 2.(x+1) has been released. But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extend depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina.
しばらくの間は，Python 2.xと Python 3.x が平行してリリースされることを期待して います。Python 2.x のリリースは Python 2.x.y というようなバグフィックスリリース より長期にわたってリリースされるでしょう。一般的には、 2.(x+1) というバージョンがリリースされるとバグフィックスリリースが行われなくなります。 しかし，Python 3.0(final) がリリースされた後も，少なくとも 1 つか 2 つの 新しい 2.x リリースがあることを望んでいます。このリリースは、 3.1 や 3.2 がリリースされる間に行われるかも知れません。 2.x をサポートすることに対するコミュニティの要求，3.0 の受け入れられ方や安定性， ボランティアの体力によって変化するかも知れません。
It's quite possible that Python 3.1 and 3.2 will be released much sooner after 3.0 than has been customary for the 2.x series. The 3.x release pattern will stabilize once the community is happy with 3.x.
Python 3.0 のリリース後すぐ，Python 2.xのリリースを待たずに 3.1 や 3.2 がリリースすることは十分にあり得ます。3.x のリリース方法はコミュニティが 3.0 を受け入れてから安定することになるでしょう。
互換性と移行
We need a meta-PEP to describe the compatibility requirements. Python 3000 will break backwards compatibility. There is no requirement that Python 2.9 code will run unmodified on Python 3.0.
Python 2.x と 3.x の互換性に関するメタ PEP が必要です。Python 3000 は後方互換性 を壊します。Python 2.9 のコードが Python 3.0 で動くことは要求されていません。
I'm not sure whether it is reasonable to require that Python 2.x code can be mechanically translated to equivalent Python 3.0 code; Python's dynamic typing combined with the plans to change the semantics of certain methods of dictionaries, for example, would make this task really hard. However, it would be great if there was some tool that did at least an 80% job of translation, pointing out areas where it wasn't sure using comments or warnings. Perhaps such a tool could be based on something like Pychecker.
Python 2.x のコードを Python 3.0 で動くように機械的に変換できるようにすべきかどうか 私は分かりません。例えば，Python は型付けが動的だし，辞書型のメソッドうちいくつかを変更 する計画があるため，2.x のコードから 3.0 のコードを機械的に生成するのは 難しいかも知れません。 しかしながら，少なくとも 80% のコードを変換できるツールがあれば大いに役に立つはず です。もしかしたら，そのようなツールは Pyckecker を元に作られるかも知れません。
Another kind of tool could be an instrumented version of 2.x which produces run-time warnings about constructs that will get a different meaning in 3.0. This can't be used for all incompatibilities, but it's likely to help reach a larger percentage of correct translations. (This approach is already in place for detecting reliance on '/' to do integer division; see Tools/scripts/fixdiv.py, which finds occurrences of int/int and long/long that were flagged by running your program with -Qwarnall.)
3.0 で別の意味を持つ機能を使った場合，実行時間中に警告表示をするツールが 2.xに追加 されることはあるかも知れません。このツールはすべての非互換性に対して役に立つわけでは ないかもしれないけれど，3.0で動くコードを書くためには大いに役立つはずです。 (このアプローチは '/' という演算子を整数型に使った場合にすでに利用されています。 Tools/scripts/fixdiv.py というファイルを見てみてください。このファイルは， "-Qwarnall" というオプションを付けたとき，整数(int)/整数や長整数(long)/長整数 が引き起こす問題を警告します)。
言語の実装
Python 3000 will be implemented in C, and the implementation will be derived as an evolution of the Python 2 code base. This reflects my views (which I share with Joel Spolsky) on the dangers of complete rewrites. Since Python 3000 as a language is a relatively mild improvement on Python 2, we can gain a lot by not attempting to reimplement the language from scratch. I am not against parallel from-scratch implementation efforts, but my own efforts will be directed at the language and implementation that I know best.
Python 3000 は C で実装します。そして，実装は Python 2 のコードベース を元にします。このことは，完全にコードを書き換えることは危険だという私の意見 (Joel Spolskyも同じ意見です)を反映しています。 Python 3000 は言語としては Python 2を 控えめに改良したものなので， 言語をまったく再実装するより利点が大きいのです。平行して再実装を進めることについて は反対しませんが，私は自分が最良と考える言語を実装することに集中したいと考えています。
メタレベルの貢献
この PEP に関する指摘はいつでも歓迎です。この文書で記述したメタ PEP に関する はもっと歓迎です。
