Python 3についての考え
最近、私はしばしばPython 3の状態についての考えで訪問されました。一見したわけではありませんが、私はPythonに夢中になり、Pythonのコースに満足しています。 私の人生はPythonで10年です。 そして、これは私の人生の大きな部分です。
事前に警告します。これは非常に個人的な記事です。 このテキストでは、1つの大文字のコピーを数えました。
これは、過去2年間で得られたすべての機会に非常に感謝しているからです。世界を旅し、人々とコミュニケーションを取り、Pythonなどの自由に分散したプロジェクトがイノベーションを促進し、人々を喜ばせる協力精神を共有する能力です。 Pythonには素晴らしいコミュニティがあり、大声で言うのを忘れがちです。
一方、私はPythonが大好きであり、方法と解決策について話し合うことを好みますが、その献身にもかかわらず、私はプロジェクトにいかなる義務も負いません。 言語に関する会議に出席すると、私は自分の提案が敵意を持って認識される理由をすぐに理解し、私自身もその破片と考えられています。 「彼は常に文句を言い、何もしません。」 Pythonで見たいことがたくさんありますが、最終的には私はそのユーザーであり、開発者ではありません。
Python 3についての私のコメントを読むと、最初のバージョンが既にリリースされていることを考えると、私はそれを嫌い、まったく切り替えたくないという印象を受けます。 私が望むように、しかし彼が今いるような形ではありません。
執筆からずっと後に人々が記事にリンクするという私の経験を考慮して、執筆時点でまずPython 3の状況を明確にしましょう：バージョン3.2がリリースされ、次のバージョンは3.3であり、Python 2.8をリリースする予定はありません。 さらに、白黒で書かれたPEPがあります。リリースはないはずです。 完全に開発されたPyPyは、そのアーキテクチャが他のすべてから非常に離れているため、誰もそれを長い間真剣に受け取らないプロジェクトです。 多くの点で、PyPyは「私はしない」ことをしますが、それは私にとって驚くべきことです。
なぜPythonを使用するのですか？
なぜPythonを使用するのですか？ これは非常に正しい質問であり、私たちはめったに尋ねないようです。 Pythonには多くの欠陥がありますが、私はとにかくそれを使用します。 今年のPyCodeConfカンファレンスの最終日に行われたパーティーでは、ニック・コフランと多くのことを話し合いました。 私たちはサポーターであり、このおかげで議論は非常に誠実であることが判明しました。 Pythonは言語として完璧ではないという事実、いくつかの欠陥については作業が継続していること、慎重に検討した上で、それらのいくつかには言い訳がないという事実を認めることに同意しました。 「からの収量」に関するPEPは、多かれ少なかれ実用的な外観を与えるために、疑わしい設計（ジェネレーターとしてのコルーチン）の開発の例として考えられました。 しかし、「yield from」で採用された変更があっても、これはすべてグリーンレットの利便性からはほど遠いものです。
この会話は、カンファレンスの同じ記念日にゲリバーナードが行った「プログラミング言語に関する偏った意見」の講義の続きでした。 Rubyブロックは素晴らしいデザインを持っているという共通の見解に至りましたが、多くの理由で、Pythonは（現在の状態では）根付かないでしょう。
個人的には、Pythonは完璧で完璧な言語であるため、Pythonを使用するとは思いません。 さらに、時間をさかのぼって以前のバージョンのPythonを見ると、非常に、いことがわかります。 Pythonが初期の頃、誰にも気付かれていなかったことに驚かないでください。
それ以来、Pythonによって得られたスコープは大きな奇跡と見なすことができるように思えます。 それが、私にはPythonを使用している理由です。この言語の進化は非常にスムーズで、具体化されたアイデアは真実でした。 初期のPythonはひどく、イテレーターの概念が欠けていました。さらに、辞書を反復処理するには、そのすべてのキーの中間リストを作成する必要がありました。 ある時点で、例外は文字列であり、文字列メソッドはメソッドではなく、同じ名前のモジュールの関数（文字列）でした。 例外をキャッチする構文は、Python 2のすべての面で苦しめられ、Unicodeは遅すぎて部分的に登場しました。
しかし、それだけではありませんでした。 せっかく、独自の名前空間を持つモジュールのアイデアは驚くべきものでした。 マルチメソッド*に基づく言語構造は、まだほとんど比類のないものです。 私たちは毎日この決定から利益を得ていますが、これについては報告していません。 この言語は常に正直に仕事をし、インタープリターで発生していること（トレースバック、スタックフレーム、オペコード、コードオブジェクト、astなど）を隠しませんでした。これは、動的構造と相まって、開発者が簡単に達成できない問題をすばやくデバッグして解決できるようにします他の言語で。
インデント構文はしばしば批判されましたが、このアプローチを導入している新しい言語（HAML、CoffeeScript、および他の多くのものが思い浮かぶ）の数を見れば、認識されていることがわかります。
Raymond *が標準ライブラリ用に新しいものを作成する方法に同意しない場合でも、そのモジュールの品質はわずかな疑問を引き起こすことはなく、これがPythonを使用する主な理由の1つです。 collectionsモジュールまたはitertoolsにアクセスせずにPythonで作業することは想像できません。
しかし、私がPythonを愛し、偶像崇拝した本当の理由は、クリスマスを待っているせっかちな子供のように、すべての新しいバージョンの期待でした。 小さな、ほとんど目立たない改善が私を魅了しました。 列挙関数のインデックスの先頭を示す機能でさえ、新しいPythonリリースに感謝しました。 そして、これはすべて後方互換性を考慮しています。
__future__からのインポートは、ときどき大嫌いなものであり、アップグレードが簡単で痛みのないものになりました。 以前はPHPを使用していましたが、新しいリリースにはまったく満足していませんでした。 PHPには名前空間はありませんでしたが、常に新しい組み込み関数があり、リリースごとに名前の競合を避けたいと本当に望んでいました（プレフィックスを使用すればそれらを回避できたことを知っていますが、それは開発の基礎を学ぶずっと前ですオン）。
何が変わった？
Pythonの新しいリリースに対応していなかったのはどうしてですか？ 私は自分のためだけに話すことができますが、他の人が新しいリリースへの態度を変えたことに気付きました。
次のPython 2.xの中核となる開発者が何をしていたのか、私は決して疑問に思いませんでした。
もちろん、たとえば抽象クラスの実装やセマンティクスの機能など、何かはそれほどよく考えられていませんでした。 しかし、基本的にはすべて、高レベルの機能に対する批判に帰着しました。
Python 3の出現により、外部要因も出現しました。そのため、言語を扱うための一般的なアプローチを突然変更する必要がありました。 以前は、この言語の新しい機能を長い間使用していませんでしたが、嬉しかったのです。 主にライブラリを作成しました。 最新かつ最高のものを使用するのは間違いです。 Werkzeugのコードは、Python 2.3での実行を許可するハックがまだ詰め込まれていますが、最小要件はバージョン2.5に引き上げられました。 一部のメーカー（悪名高いApple）は、重大な脆弱性が見つかるまでインタープリターを更新しないため、コードに標準ライブラリのバグ修正を残しました。
これはすべてPython 3では不可能です。これにより、すべてが2.xまたは3.xの開発に変わります。 そして、中間決定は期待されていません。
Python 3の発表後、Guidoは常に2to3とそれが移植を容易にする方法について喜んで語っていました。 しかし、2to3はPythonに起こりうる最悪の事態であることが判明しました。
2to3を使用してJinja2を移植する際に大きな困難を経験しましたが、後悔しました。 さらに、レンダリングされたJSON Jinjaプロジェクトでは、2to3が正しく動作するように記述されたハックをすべて削除しました。 他の多くの人と同様に、現在、バージョン2.xと3.xの両方で機能するコードを維持するために最善を尽くしています。 なぜだろう？ 2to3は非常にゆるやかであるため、テストプロセスへの統合が不十分であり、使用されるPython 3のバージョンに依存し、ブラックマジックの使用を除いて他のすべてを構成できます。 これは痛みを伴うプロセスであり、ライブラリの作成から得られる喜びをすべて無効にします。 私はJinja2をトリミングするのが好きでしたが、Python 3のポートの準備ができたときにそれをやめました。 何かを壊すのが怖かった。
現在、共有コードベースのアイデアは、バージョン2.5までのPythonをサポートする必要があるという事実に基づいています。
Python 3によって引き起こされた変更により、すべてのコードが使用できなくなったため、コードをすぐに書き換えてアップグレードする言い訳にはなりません。 私の深く主観的な意見では、Python 3.3 / 3.4はPython 2に似ていて、Python 2.8はPython 3に近いはずです。プログラミング言語の世界では、Python 3はXHTMLでした。 それは、置き換えようとしているものと互換性がなく、見返りとして、より「正しい」ことを除いて実質的に何も提供しません。
ユニコードについて少し
明らかに、Python 3の最大の変更点はUnicodeの処理でした。 すべての人とすべての人にユニコードを植えることは祝福のように思えるかもしれません。 それでも、これはピンクの眼鏡を通して見た世界です。現実の世界では、バイトとユニコードだけでなく、よく知られたエンコーディングの文字列にも直面しているからです。 何よりも、多くの点で、Python 3はプログラミング言語の世界で一種のFisher Price *になりました。 以降、一部の機能が削除されました カーネル開発者は、「簡単にカットできる」と感じました。 そして、これらはすべて、広く使用されている機能を削除するという犠牲を払って行われました。
具体例を次に示します。3.xのコーデックを使用した操作は、現在Unicode <->バイト変換に制限されています。 バイト<->バイトまたはUnicode <-> Unicodeはありません。 理にかなっているように見えますが、よく見ると、このリモート機能が非常に重要であることがわかります。
Python 2のコーデックシステムの最も注目すべき機能の1つは、膨大な数のエンコードとアルゴリズムを使用した多様な作業を目的として作成されたことです。 コーデックを使用して文字列をエンコードおよびデコードできます。また、ストリームやその他の不完全なデータに対する操作を提供するオブジェクトをコーデックに要求することもできます。 それでも、コーデックシステムは、コンテンツエンコーディングと転送エンコーディングで同等に機能しました。 システムの各部分が自動的に学習するため、新しいコーデックを作成して登録する価値がありました。
PythonでHTTPライブラリを記述することを引き受けた人は誰でも、コーデックがUTF-8（実際の文字エンコーディング）のデコードだけでなく、gzip（圧縮アルゴリズム）にも使用できることを喜んで発見しました。 これは文字列だけでなく、ジェネレーターまたはファイルオブジェクトにも適用されます。もちろん、それらの使用方法を知っている場合を除きます。
現時点では、Python 3では、これらのすべてが単純に機能しません。 これらは文字列オブジェクトからこれらの関数を削除しただけでなく、バイト->バイトエンコーディングも削除し、何も返しません。 間違っていなければ、問題を認識し、上記の機能を3.3に戻すことについて議論を始めるのに3年かかりました。
次に、Unicodeはまったく属していない場所にプッシュされました。 そのような場所には、ファイルシステムレイヤーとURLモジュールが含まれます。 それでも、70年代に住んでいるプログラマーの観点から、多くのUnicode機能が作成されました。
UNIXファイルシステムはバイトベースです。 そのため、整理されており、何もできません。 当然、既存のコードを壊すことなく実際にこれを変更することは素晴らしいことです。 エンコードの変更は、ユニコード指向のファイルシステムに必要なもののほんの一部にすぎないためです。 さらに、正規化フォームの質問と、すでに実行された正規化による登録情報の保存に関する質問は未解決のままです。 バイト文字列型がPython 3に残っていれば、これらの問題は回避できたはずです。 ただし、それは存在せず、その置換であるバイト型は、文字列の動作とは異なります。 文字列として同時に存在するバイトデータを使用して人々を罰するために記述されたデータ型のように動作します。 プログラマーがこれらの問題を解決できるツールとして開発されていないようです。 現実以上の問題。
したがって、Python 3のファイルシステムを使用している場合、サロゲートペアとシールドを使用した新しいエンコーディングが存在しても、不思議な気持ちになりません。 これは痛みを伴うプロセスであり、この大騒ぎをかき集めるためのツールがないため、痛みを伴います。 「バディ、Unicodeファイルシステムはこれからです」というPython 3の種類がありますが、この混乱をどこから解決する必要があるかについては説明していません。 ファイルシステムが実際にUnicodeをサポートしているかどうか、またはPythonがこのサポートを偽装しているかどうかも明確にはなりません。 正規化に関する詳細やファイル名の比較方法については公開していません。
それは実験室で機能しますが、現場では故障します。 私のポピーにはアメリカのキーボードレイアウト、アメリカのロケールがあり、日付と数字の形式が異なることを除いて、ほとんどすべてがアメリカのものです。 このすべての結果として（そしてTigerの時代からポピーをアップグレードしたと仮定すると）、次のような状況に陥りました：リモートサーバーに移動して、ロケールを文字列値 "POSIX"に設定しました。 どのような「POSIX」ですか？ そして、地獄は知っています。 そこで、私と同じ無知なPythonは、「ANSI_X3.4_1968」で作業することにしました。 この記念すべき日に、ASCIIには多くの名前があることを知りました。 これはASCII名の1つにすぎないことが判明しました。 それでは、リモートPythonインタープリターが、ディレクトリの内容を国際化されたファイル名で誤って表示しました。 彼らはどうやってそこに着いたのですか？ ウィキペディアの記事に元の名前を付けて投げました。 Python 3.1を使用してこれを行いました。Python3.1は、例外をスローしたり、ハックを使用したりする代わりに、ファイルで何が起こっているかについて沈黙していました。
しかし、ファイルシステムの誤動作は単なる花です。 Pythonはまた、環境変数（ご存じのとおり、ゴミでいっぱいです）を使用して、デフォルトのファイルエンコーディングを設定します。 会議中、私は2、3人の訪問者に、Python 3のテキストファイルにデフォルトで使用されるエンコーディングを推測するように依頼しました。この小さなサンプルの90％以上がUTF-8であると確信していました。 そしていや！ プラットフォームのロケールに応じてインストールされます。 あなたが言ったように、70年代からの挨拶。
おもしろいことに、私が制御する両方のサーバーにログインしましたが、どちらか一方がコンソールからログインするときにlatin1エンコードを持ち、rootでsshを介してログインするとlatin15に切り替わり、ユーザーアカウントを使用してログインした場合はUTF-8になりました。 くそ楽しいが、自分だけが責任を負います。 デフォルトでは、SSHがログイン時にロケール設定を送信することを考えると、サーバーが魔法のようにエンコーディングを切り替えるのは私だけではないことは間違いありません。
なぜこれについてここに書いているのですか？ はい、Python 3でのUnicodeサポートがPython 2よりもはるかに厄介なことを何度も証明する必要があるためです。
Unicodeのエンコードとデコードは、「明示的は暗黙的よりも優れている」という点で、Zen Python 2を使用している人の邪魔になりません。 「バイトが入ってきて、ユニコードが出ます」-これが、他のサービスと通信するアプリケーションの一部が機能する方法です。 これは説明できます。 あなたはそれを文書化することでうまく説明できます。 ユニコード形式の内部テキスト処理には理由があることを強調します。 私たちの周りの世界は過酷で、バイトに基づいていることをユーザーに伝えるため、この世界と通信するにはエンコードとデコードが必要です。 この概念はユーザーにとって新しいものかもしれません。 しかし、あなたは正しい言葉を見つけて、すべてをうまく塗らなければなりません。
なぜそんな自信を持ってこれについて話しているのですか？ 2006年以来、私のプログラムはすべてUnicodeユーザーをプッシュしているため、Unicodeに関するクエリの数は、パッケージまたはインポートシステムの操作に関するブレークスルーと比較することはできません。 Pythonの領域であるdistutils2でも、パッケージはUnicodeよりもはるかに大きな問題のままです。
イベントの自然な発展とはほど遠い：UnicodeをPython 3ユーザーから隠しますが、すべてがどのように機能するかを想像するのはより困難であることが判明しました。 先験的な暗黙の動作が必要ですか？ よくわからない。
確かに、Python 3は現在正しい軌道に乗っています。 私は、より多くの話がいくつかのバイトAPIを返すことについてであることがわかりました。 私の素朴なアイデアは、Python 3の3番目のタイプの文字列であるestrなどのアイデアです。 Python 2のstrとまったく同じように機能し、バイトを格納し、同じ文字列APIのセットを持ちます。 ただし、Unicode文字列への透過的なデコードやバイトオブジェクトへのキャストに使用されるエンコード情報も含まれます。 このタイプは、移植を容易にする聖杯となります。
しかし、それは存在せず、Pythonインタープリターは、さらに別のタイプのストリング用に予約されていませんでした。
彼らの世界を破壊した
ニックは、Pythonコアの開発者がWebプログラマーの世界をどのように破壊したかについて話しました。 これまでのところ、破壊はPythonの後方非互換性が終わるところまで広がっています。 しかし、私たちの世界は他の開発者の世界ほど破壊されませんでした。 結局のところ、1つの世界があります。 ネットワークは暗号化されたバイトに基づいていますが、これは主に低レベルのプロトコルに関するものです。 下位レベルにあるもののほとんどとの通信は、エンコードを使用したバイト言語で行われます。
ただし、主な変更は考え方に影響を与え、これらのレベルで作業するときに必要になります。 Python 2はUnicodeオブジェクトを非常に頻繁に使用して、下位レベルと通信しました。 必要に応じて、オブジェクトはバイト単位でエンコードされ、その逆も同様です。 たとえば、私たちにとって好ましい副作用は、データを初期段階でエンコードおよびデコードし、ユニコードを理解するチャネルに転送することにより、一部の操作を高速化できることでした。 これにより、多くの点で、シリアル化モジュールがカーネルで機能できるようになります。 たとえば、Pickleは、バイトとUnicodeの両方をサポートするストリームと通信します。 ある程度、simplejsonについても同じことが言えます。 そして、Python 3が登場します。そこでは突然、Unicodeストリームとバイトストリームを分離する必要があります。 多くのAPIは、インターフェイスに大きな変更がない限り、Python 3への道で生き残れません。
はい、これはより正しいアプローチですが、実際には、彼はより正確であることを除いて、もはや利点を持ちません。
Python 3でI / O機能を操作するとき、私はそれが素晴らしいことを確認しました。 しかし実際には、Python 2の仕組みと比較することはできませんが、多くの偏見を持っているように見えるかもしれません。同じ機能を達成することは、悪い形と見なされます。 そして、Python 3では、すべての側面を考慮して、これをすべて行わなければなりません。
しかし、移植は機能します！
もちろん、Python 3への移植は機能します。 それは証明されており、何度も繰り返されています。 しかし、何かが可能であり、すべてのテストに合格したからといって、すべてがうまくいっているわけではありません。 私は障害のある人で、多くの間違いを犯します。 同時に、お気に入りのAPIを輝かせようと努力しています。 時々、コードをより使いやすくするために何度も何度も書き直していることに気づきます。 Flaskで作業するとき、私はコア機能を磨くのに多くの時間を費やしたので、強迫観念について話し始める時が来ました。
私はそれが完璧に機能することを望んでいます。 一般的なタスクにAPIを使用する場合、Porsheの設計と同じレベルの卓越性が必要です。 はい、これは開発者の外層にすぎませんが、製品は最初から最後まで十分に開発する必要があります。
Python 3でコードを「機能させる」ことができますが、それでも嫌いです。 私はそれが機能したいです。 しかし、同時に、自分のライブラリや他の人のライブラリを使用して、Python 2で得られるのと同じ喜びをPython 3で実現したいと考えています。
たとえば、Jinja2は、実行時に実装を切り替えることなく2.xと3.xで同じコードを使用することはできないため、Python 3の入力/出力レイヤーを正しく使用しません。 現在、テンプレートは2.xと3.xの両方でバイナリモードで開きます。 これが唯一の信頼できるアプローチであり、その後、Jinja2自体がこのバイナリストリームからデータをデコードします。 実際、改行セパレーターの正規化のおかげで、これは機能します。 しかし、Windowsで働いていて、自分自身で行区切り記号を正規化していない人は、遅かれ早かれ、これをまったく知らずにさまざまな区切り記号からマッシュになってしまうことは間違いありません。
Python 3を取る
Python 3は大きく変わりました。それは事実です。 間違いなく、私たちが向かっている未来はその背後にあります。 Python 3には多くの可能性があります。インポートシステムの大幅な改善、__ qualname__の出現、Pythonパッケージの新しい配布方法、メモリ内の文字列の統一表現。
しかし、今のところ、ライブラリをPython 3に移植することは、Python 2でライブラリを開発し、動作することを証明するためだけにPython 3のスマート尻バージョンを使用してライブラリを作成するようです。 Python 3のJinja2については、あらゆる点で、それはひどいugだと言えるでしょう。 これは恐ろしいことであり、私はそれを恥じるべきです。 たとえば、Python 3のバージョンでは、Jinja2は2つの1メガバイトの正規表現をメモリにロードしましたが、解放することは絶対に気にしませんでした。 私は彼女に何とかして働きたかっただけです。
では、なぜJinja2でメガバイトの正規表現を使用する必要があったのですか？ はい、Pythonの正規表現エンジンはUnicodeカテゴリをサポートしていないためです。 そして、このような制限があるため、Python 2の新しいUnicode識別子にハンマーをかけてASCII識別子に制限するか、必要な定義をすべて入力して巨大な正規表現を手動で作成するという2つの弱さを選択する必要がありました。
上記は、Python 3の準備ができていない理由を説明する最良の例です。それは、独自のイノベーションを扱うためのツールを提供していません。 Python 3はUnicode指向の正規表現に不可欠であり、Unicodeを考慮したロケールで動作するAPIが必要です。 彼は、基礎となるファイルシステムの動作を公開する、より高度なパスモジュールが必要です。 ランタイム環境に関係なく、テキストファイルに単一の標準エンコーディングを強く課す必要があります。 エンコードされた文字列を操作するためのより多くのツールを提供する必要があります。 彼はURLだけでなく、IRIのサポートが必要です。 彼は、それ以上の何かを必要としています。 URLをファイルシステムにマッピングするために必要な、トランスコーディング用の補助メカニズムが必要です。
上記のすべてに、Python 2.8のリリースを追加できます。これは、Python 3に少し近くなります。私にとって、Python 3に切り替える現実的な方法は1つしかありません。ライブラリとプログラムは、完全にUnicodeを認識し、新しいPython 3エコシステムに統合する必要があります。
アマチュアに道を開かせないでください
Python 3の最大の間違いは、Python 2とのバイナリ非互換性です。ここでは、Python 2とPython 3のインタープリターが共通のプロセス空間で一緒に動作できないことを意味します。 そのため、Python 2とPython 3の両方のスクリプトインターフェイスと同時にGimpを起動することはできません。vimとBlenderにも同じことが当てはまります。 私たちは単にできません。 別々のプロセスと芸術的なIPCを使ってたくさんのハックを書くことは難しくありませんが、誰もそれを必要としません。
したがって、他の人がPython 3を棒の下から習得する前にPython 3を習得しなければならないプログラマー。 そして、このプログラマーが一般的にPythonに精通しているということは事実ではありません。そして、正直なところ、お金はPython 2を中心に回っているためです。夜にPython 3にすべてのエネルギーを費やしたとしても、午後にはまだPython 2に戻ることになります。しかし、多くのグラフィックデザイナーがPython 3の下でBlenderでスクリプトを書き始める場合、ここで必要な適応があります。
私は本当にカック・チーズショップを見たくありません*Python 3のポートポートの曲がり具合に悩まされます。別のJinja2と、2.xと3.xで動作するように設計された特にいコードの束は、見たくありません。構文の違いを回避するためのsys.exc_info（）[1]のようなハック、2.xおよび3.xとの互換性のために実行時にリテラルを変換するためのハックなどがあります。これらはすべて、実行時のパフォーマンスだけでなく、Pythonの中核となるハックのない美しく読みやすいコードにも大きく反映されています。
失敗を認識し、学び、適応する
今こそ、私たちが集まって、2.xと3.xでコードを操作するために行うすべてのことについて話し合うときです。技術は急速に進化していますが、地平線上の暗い雲を見失ったという理由だけで、Pythonがばらばらになるのを非常に残念に思います。
Pythonは「忘れるには大きすぎません」。彼はすぐに人気を失う可能性があります。 PascalとDelphiは、C＃と.NETフレームワークの誕生後も驚くべき言語のままであったにもかかわらず、狭いニッチに陥りました。とりわけ、経営陣は転倒の影響を受けました。人々はまだPascalで開発を進めていますが、新しいプロジェクトを書き始めている人は多いのでしょうか？ Deplhiは、iPhoneおよびAndroidでは動作しません。 UNIX市場にはあまりうまく統合されていません。そして正直に言うと、Pythonはすでにいくつかの分野で地歩を失っています。 Pythonはコンピューターゲームの分野で非常に人気がありましたが、この列車は長い間なくなっています。 Webコミュニティでは、新しい競合他社は雨上がりのキノコのように見えますが、私たちが好むと好まざるとにかかわらず、JavaScriptはスクリプトプログラミング言語としてのPythonの位置をますます仮定します。
Delphiは時間内に適応できず、人々は単に他の技術に切り替えました。2to3がPython 3への移行パスである場合、py2jsはJavaScriptへの移行パスです。
そして、ここに私が提案するものがあります：Python 3への移行を複雑にするすべてのリストと、これらの問題を解決するためのソリューションのリストを作成できますか？移植に役立つ場合、Python 2.8開発について再検討できますか？PyPyを、コードの記述方法に影響を与えるほど強力な、有効なPython実装として認識できますか？
アーミンロナッチャー、
2011年12月7日。
翻訳者から：この記事を読んだ後、最初の欲求は他の人と共有することでしたが、「世界が知っておくべき」という鋭い感覚がありました。同僚のイリーナ・ピロゴワと妻のアイラ・メディエワが記事の再執筆を手伝ってくれました。