私はPythonの3番目のバージョンとこのプログラミング言語が開発している方向が好きではないことを誰もが知っています。 過去数ヶ月にわたって、Python開発の私のビジョンについて尋ねる多くの手紙を受け取りました。可能であれば、将来の言語開発者に意見を述べるためにコミュニティで意見を共有することにしました。



確かに言うことができます：Pythonは理想的なプログラミング言語ではありません。 私の意見では、主な問題は通訳者の特徴に起因し、言語自体とはほとんど関係がありませんが、通訳者のこれらすべてのニュアンスは徐々に言語自体の一部となり、したがってそれらは非常に重要です。



奇妙な通訳者（スロット）と会話を始め、言語アーキテクチャの最大の誤りで会話を終わらせたいと思います。 実際、この一連の投稿は、インタープリターアーキテクチャに組み込まれたソリューションと、インタープリターと言語自体の両方に対する影響の調査です。 このような記事は、言語の一般的な設計の観点から、単にPythonの改善に関する考えを述べるよりもはるかに興味深いものになると思います。

言語と実装

このセクションは、記事全体を書いた後に追加されました。 私の意見では、一部の開発者は、言語としてのPythonとインタープリターとしてのCPythonの関係の事実を見落とし、それらは互いに独立していると信じています。 はい、言語の仕様はありますが、多くの場合、インタープリターの作業を説明するか、いくつかの点について単に黙っています。



このアプローチでは、インタープリターのインプリメンテーションの暗黙的な詳細が言語のアーキテクチャーに直接影響し、他のPythonインプリメンテーションにいくつかのことを採用させることさえあります。 たとえば、PyPyはスロットについては何も知りませんが（私の知る限り）、スロットがその一部であるかのように動作することを強制されます。

スロット

私の意見では、言語の最大の問題の1つはばかげたスロットシステムです。 __slots__コンストラクトについてではなく、特別なメソッドの内部型スロットを意味します。 これらのスロットは、言語の「機能」であり、多くの人が見落としがちです。ほとんどの人がそれを処理する必要がないからです。 さらに、スロットの存在そのものがPython言語の最大の問題です。



スロットとは何ですか？ これは、インタープリターの内部実装の副作用です。 すべてのPythonプログラマーは、 __ add__などの「マジックメソッド」について知っています 。これらのメソッドは、名前が囲まれている2つのアンダースコアで始まり、2つのアンダースコアで終わります。 各開発者は、コードにa + bを記述すると、インタープリターによって関数a .__ add __（b）が呼び出されることを知っています。



残念ながら、これは真実ではありません。



実際、Pythonはそのようには機能しません。 Pythonは内部的にはそのように動作しません（少なくとも現在のバージョンでは）。 インタープリターの仕組みは次のとおりです。

1. オブジェクトが作成されると、インタープリターはすべてのクラス記述子を見つけ、 __add__などの魔法のメソッドを探します。
2. 検出された各特殊メソッドについて、インタープリターは記述子リンクをオブジェクトの特別に割り当てられたスロットに配置します。たとえば、マジックメソッド__add__は、 tp_as_number-> nb_addおよびtp_as_sequence-> sq_concatの 2つの内部スロットに関連付けられます。
3. インタープリターがa + bを実行する場合、 TYPE_OF（a）-> tp_as_number-> nb_add（a、b）のようなものを呼び出します（実際、 __ add__メソッドには複数のスロットがあるため、すべてがより複雑になります）。

操作a + bは、 タイプ（a）.__ add __（a、b）のようなものでなければなりませんが、スロットの操作から見たように、これは完全に真実ではありません。 メタクラスメソッド__getattribute__をオーバーライドし、独自の__add__メソッドを実装しようとすると、これを自分で簡単に確認できます。このメソッドは呼び出されないことに気付くでしょう。



私の意見では、スロットシステムは単純にばかげています。 これは、一部のタイプのデータ（整数など）を操作するための最適化ですが、他のオブジェクトにはまったく意味がありません。



これを実証するために、このような無意味なクラス（ x.py ）を作成しました。

class A(object): def __add__(self, other): return 42
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

__add__メソッドを再定義したため、インタープリターはそれをスロットに配置します。 しかし、それがどれくらい速いかを確認しましょう。 操作a + bを実行するとき、スロットシステムを使用します。プロファイリングの結果は次のとおりです。

 $ python3 -mtimeit -s 'from x import A; a = A(); b = A()' 'a + b' 1000000 loops, best of 3: 0.256 usec per loop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

操作a .__ add __（b）を実行すると、スロットシステムは使用されず、代わりにインタープリターはクラスインスタンスのディクショナリ（何も見つからない場所）、さらに、目的のメソッドが見つかるクラス自体のディクショナリになります。 測定値は次のようになります。

 $ python3 -mtimeit -s 'from x import A; a = A(); b = A()' 'a.__add__(b)' 10000000 loops, best of 3: 0.158 usec per loop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

信じられますか？ スロットを使用しないオプションは、スロットを使用するオプションよりも高速でした。 魔法？ 私はこの振る舞いの理由を完全には確信していませんが、これは長い間、非常に長い間続いています。 実際、古いタイプクラス（スロットがない）は、新しいタイプクラスよりもはるかに高速に機能し、より多くの機能を備えていました。



より多くの機能が必要ですか？ はい、古いタイプのクラスはこれを行うことができるため（Python 2.7）：

 >>> original = 42 >>> class FooProxy: ... def __getattr__(self, x): ... return getattr(original, x) ... >>> proxy = FooProxy() >>> proxy 42 >>> 1 + proxy 43 >>> proxy + 1 43
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今日、Python 2よりも複雑な型システムを持っているにもかかわらず、選択肢が少なくなっています。 上記のコードは、新しいタイプのクラスを使用して実行できません。 実際、古い型クラスがどれほど軽量であったかを考慮すると、さらに悪化します。

 >>> import sys >>> class OldStyleClass: ... pass ... >>> class NewStyleClass(object): ... pass ... >>> sys.getsizeof(OldStyleClass) 104 >>> sys.getsizeof(NewStyleClass) 904
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スロットシステムはどこから来たのですか？

上記のすべては、スロットがどこから来たかという問題を提起します。 私が知る限り、それは長い伝統でした。 Pythonインタープリターが最初に作成されたとき、組み込み型（たとえば、文字列）はグローバルな静的構造として実装されていたため、オブジェクトに必要なこれらのすべての特別なメソッドを含める必要がありました。 これは、 __ add__メソッド自体が現れる前でした 。 1990年の最も古いバージョンのPythonを見ると、その時点でオブジェクトがどのように実装されていたかがわかります。



ここで、たとえば、整数はどのように見えましたか：

 static number_methods int_as_number = { intadd, /*tp_add*/ intsub, /*tp_subtract*/ intmul, /*tp_multiply*/ intdiv, /*tp_divide*/ intrem, /*tp_remainder*/ intpow, /*tp_power*/ intneg, /*tp_negate*/ intpos, /*tp_plus*/ }; typeobject Inttype = { OB_HEAD_INIT(&Typetype) 0, "int", sizeof(intobject), 0, free, /*tp_dealloc*/ intprint, /*tp_print*/ 0, /*tp_getattr*/ 0, /*tp_setattr*/ intcompare, /*tp_compare*/ intrepr, /*tp_repr*/ &int_as_number, /*tp_as_number*/ 0, /*tp_as_sequence*/ 0, /*tp_as_mapping*/ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、Pythonの最初のバージョンでも、 tp_as_numberメソッドはすでに存在していました。 残念ながら、古いバージョンのPython（特に、インタープリター）はリポジトリの損傷により失われたため、オブジェクトがどのように実装されているかを確認するために、少し新しいバージョンを見てみましょう。 これは、1993年の関数追加コードの外観です。

 static object * add(v, w) object *v, *w; { if (v->ob_type->tp_as_sequence != NULL) return (*v->ob_type->tp_as_sequence->sq_concat)(v, w); else if (v->ob_type->tp_as_number != NULL) { object *x; if (coerce(&v, &w) != 0) return NULL; x = (*v->ob_type->tp_as_number->nb_add)(v, w); DECREF(v); DECREF(w); return x; } err_setstr(TypeError, "bad operand type(s) for +"); return NULL; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それで、 __ add__や他の人はいつ生まれましたか？ バージョン1.1で登場したと思います。 OS X 10.9でPython 1.1をコンパイルできました。

 $ ./python -v Python 1.1 (Aug 16 2014) Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、このバージョンは安定しておらず、すべてが正常に機能するわけではありませんが、当時のPythonのアイデアを得ることができます。 たとえば、CとPythonでのオブジェクトの実装には大きな違いがありました。

 $ ./python test.py Traceback (innermost last): File "test.py", line 1, in ? print dir(1 + 1) TypeError: dir() argument must have __dict__ attribute
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、整数などの組み込み型のイントロスペクションがなかったことがわかります。 実際、 __ add__メソッドはカスタムクラスでのみサポートされていました。

 >>> (1).__add__(2) Traceback (innermost last): File "<stdin>", line 1, in ? TypeError: attribute-less object
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが、今日Pythonで得たレガシーです。 Pythonオブジェクトのアーキテクチャの基本原則は変更されていませんが、長年にわたって、多くの改良、変更、リファクタリングが行われてきました。

モダンPyObject

今日、多くの人が、Cで実装されたPythonの組み込みデータ型とPythonで実装された純粋なオブジェクトの違いは重要ではないという主張に異論を唱えるでしょう。 Python 2.7では、この違いは、 __ repr__メソッドが Pythonで実装された型の対応するクラスクラスによって提供され、したがって、Cで実装された組み込みオブジェクトの型で提供されるという事実で特に顕著です。実際、この違いはオブジェクトの配置を示します：静的に（ typeの場合 ）またはヒープ内で動的に（ classの場合 ）。 実際には、この違いは何の違いももたらさず、Python 3では完全に消えました。 特別なメソッドはスロットに配置され、その逆も同様です。 PythonクラスとCクラスの違いはもうないようです。



ただし、違いはまだあり、非常に顕著です。 それを理解しましょう。



ご存じのとおり、Pythonのクラスは「オープン」です。 これは、クラス宣言が完了した後でも、それらを「覗き」、それらに格納されている内容を表示し、メソッドを追加または削除できることを意味します。 ただし、組み込みのインタープリタークラスにはこのような柔軟性はありません。 なぜそう



たとえば、 dictオブジェクトに新しいメソッドを追加するための技術的な制限はありません。 インタープリターがこれを許可していない理由は、開発者の健全性とはほとんど関係がありません。事実は、組み込みデータ型がヒープ上にないためです。 このグローバルな意味を理解するには、まずPythonがインタープリターを実行する方法を理解する必要があります。

くそー通訳

Pythonでインタープリターを実行するのは非常に高価なプロセスです。 実行可能ファイルを実行すると、すべてよりも少しだけ多くのことができる複雑なメカニズムをアクティブにします。 とりわけ、組み込みデータ型、モジュールインポートメカニズムが初期化され、いくつかの必要なモジュールがインポートされ、オペレーティングシステムで作業が実行され、信号とコマンドラインパラメーターで作業を構成し、インタープリターの内部状態がセットアップされます。 そして、これらすべてのプロセスが終了した後にのみ、インタープリターがコードを開始し、作業を完了します。 そのため、Pythonは25年間働いています。



擬似コードでは次のようになります。

 /*   */ bootstrap() /*        ,   */ initialize() rv = run_code() finalize() /*   */ shutdown()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は、インタープリターには膨大な数のグローバルオブジェクトがあり、実際にはインタープリターが1つあることです。 さらに良いことに、アーキテクチャの観点からは、インタプリタを初期化し、次のように実行する必要がありました。

 interpreter *iptr = make_interpreter(); interpreter_run_code(iptr): finalize_interpreter(iptr);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが、他の動的プログラミング言語、たとえばLua、JavaScriptなどの仕組みです。 主な機能は、2つのインタープリターを使用できることです。これは新しい概念です。



誰が複数の通訳を必要とするでしょうか？ びっくりするでしょうが、Pythonの場合でもこれが必要です。少なくとも、それは有用です。 既存の例の中で、 mod_python上のWebアプリケーションなど、組み込みPythonを使用してアプリケーションに名前を付けることができます-それらは必ず隔離された環境で実行する必要があります。 はい、Pythonにはサブインタープリターがありますが、サブインタープリターはメインインタープリター内で機能します。これは、Pythonの内部状態に多くが関連付けられているためです。 Pythonの内部状態を操作するための最大のコードは、同時に最も物議をかもしているグローバルインタープリターロック（GIL）です。 Pythonはすべてのサブインタープリターによって共有される膨大な量のデータがあるため、単一のインタープリターの概念で機能します。 これらすべては、このデータへの唯一のアクセスのためにロック（ロック）を必要とするため、このロックはインタープリターに実装されています。 どのようなデータについて話しているのでしょうか？



上記のコードを見ると、これらの巨大な構造がすべてグローバル変数として宣言されていることがわかります。 実際、インタープリターはマクロOB_HEAD_INIT（＆Typetype）を使用してこれらの構造を直接Pythonコードで使用します。これにより、これらの構造に必要なヘッダーがインタープリターで動作するように設定されます。 たとえば、オブジェクトへのリンクの数のカウントがあります。



今、あなたはすべてが起こっている場所を見ますか？ これらのオブジェクトは、すべてのサブインタープリターによって共有されます。 ここで、Pythonコードでこれらのオブジェクトのいずれかを変更できることを想像してください。2つの完全に独立した、相互に接続されていないPythonプログラムは、何もバインドしてはならず、相互の状態に影響を与えることができます。 たとえば、FacebookのタブのJavaScriptコードが組み込みの配列オブジェクトの実装を変更し、Googleのタブでこれらの変更がすぐに機能し始めると想像してください。



これは1990年のアーキテクチャソリューションであり、現在のバージョンの言語に影響を与え続けています。



一方、可変データ型の問題は他のプログラミング言語でもよく知られているため、組み込み型全体の不変性はPython開発者コミュニティから好意的に受け取られました。



ただし、もう1つあります。

VTableとは何ですか？

そのため、Pythonでは、組み込み（Cで実装）データ型はほとんど不変です。 彼らは他にどのように違いますか？ もう1つの違いは、Pythonクラスの「オープン性」です。 Pythonプログラミング言語で実装されるクラスメソッドは「仮想」です。C++のような仮想メソッドの「実際の」テーブルはなく、すべてのメソッドは、検索アルゴリズムを使用して選択が行われるクラスの辞書に格納されます。 結果は明らかです。オブジェクトから継承してそのメソッドを再定義すると、別のメソッドがプロセス内で呼び出されるため、間接的に影響を受ける可能性があります。



使いやすい関数を含むコレクションが良い例です。 したがって、Pythonの辞書には、オブジェクトを取得するための2つのメソッド、 __getitem __（）とget（）があります。 Pythonでクラスを作成するとき、通常、1つのメソッドを別のメソッドに実装し、たとえばget（key）関数からself .__ getitem __（key）を返します。



インタープリターに実装された型の場合、すべてが異なります。 この理由も、スロットと辞書の違いです。 インタープリターでディクショナリーを作成し、既存のコードを再利用することが条件の1つであるため、 getから__getitem__を呼び出すとします 。 あなたは何をしますか？



CのPythonメソッドは特定のシグネチャを持つ単なる関数であり、これが最初の問題です。 関数の主なタスクは、Pythonコードのパラメーターを処理し、レベルCで使用できるものに変換することです。少なくとも、タプルまたはPython辞書（argsおよびkwargs）からの関数呼び出しの引数をローカル変数に変換する必要があります。 通常、彼らはこれを行います：最初に、 dict__getitem__は引数を解析し、次にdict_do_getitemが現在のパラメーターで呼び出されます。 何が起こっているのかわかりますか？ dict__getitem__とdict_getはどちらも内部静的関数であるdict_getを呼び出しますが、それについては何もできません。



この制限を回避する良い方法はありません。その理由はスロットシステムです。 インタープリターがvtableを介して呼び出しを行う通常の方法はなく、その理由はGILです。 辞書（dict）は、アトミック操作を使用してAPIを介して「外の世界」と通信し、vtableを介してこのような呼び出しが発生すると、これは完全に意味を失います。 なんで？ はい、そのような呼び出しはPythonレベルに到達しない可能性があり、GILを介して処理されないため、すぐに大きな問題につながります。



辞書から継承されたクラスで、遅延インポートが実行される内部dict_get関数をオーバーライドする苦痛を想像してください。 あなたは窓からすべての保証を捨てます。 しかし、もう一度、おそらくこれをずっと前にやるべきだったのでしょうか？

おわりに

近年、Python言語を複雑にする傾向が明らかになっています。 私は反対を見たいです。



このインタープリターの内部アーキテクチャは、JavaScriptでの動作と同様に、ローカルベースデータ型の独立したサブインタープリターに基づいている必要があります。 これにより、メッセージングに基づく埋め込みとマルチスレッド化の最も広い可能性が開かれます。 プロセッサはもはや高速ではなくなります。



vtableロールのスロットと辞書の代わりに、辞書を試してみましょう。 Objective-C言語はメッセージングに完全に基づいており、これはその速度において決定的な役割を果たします。Objective-Cでの呼び出しの処理はPythonよりもはるかに速いことがわかります。 文字列はPythonの内部型であるという事実により、文字列をすばやく比較できます。 提案されたアプローチが悪化することはないと確信しており、これにより内部型の作業が遅くなったとしても、最適化が容易なはるかにシンプルなアーキテクチャになるはずです。



Pythonソースコードを調べて、スロットシステムが機能するために必要な追加コードの量を確認する必要があります。信じられないほどです。 これは悪い考えだと確信しており、私たちはずっと前にそれを放棄すべきだった。 作成者はCPythonとの互換性モードでインタープリターを動作させるために邪魔にならないと確信しているので、スロットを拒否することはPyPyにも利益をもたらします。



Dreadatourを翻訳し、テキストは％username％を読みました。