これは、「Python、どのように見たいか」に関する私の考えの2番目の部分であり、その中で型システムを詳しく見ていきます。 これを行うには、Python言語とそのインタープリターCPythonの機能を再度調査する必要があります。



あなたがPythonプログラマーである場合、データ型は常に背後に残っています。 どこかでそれらは自分自身で存在し、何らかの形で相互作用しますが、ほとんどの場合、エラーが発生した場合にのみ存在について考えます。 そして、例外は、データ型の1つが期待どおりに動作しないことを示しています。



Pythonは、型システムの実装を常に誇りに思っています。 何年前にドキュメントを読んだか覚えていますが、そこにはアヒルのタイピングの利点に関するセクション全体がありました。 正直に言ってください。はい、実用的な目的のために、アヒルのタイピングは良い解決策です。 何にも制限されておらず、データ型が存在しないためにデータ型を処理する必要がない場合は、非常に美しいAPIを作成できます。 Pythonは、日常のタスクを解決するのが特に簡単です。



Pythonで実装したほとんどすべてのAPIは、他のプログラミング言語では機能しませんでした。 コマンドラインインターフェース （ クリックライブラリ）のような単純なものでさえ、他の言語では機能しません。主な理由は、データ型と常に闘わなければならないことです。



少し前に、Pythonに静的型付けを追加するという問題が提起されました。私は、氷がついに壊れたことを心から願っています。 私はなぜ明示的な型付けに反対するのか、そしてなぜPythonがこの道を決して進まないのかを説明しようとします。

「型システム」とは何ですか？

型システムは、どの型が相互作用するかに応じた一連のルールです。 データ型のみに専念するコンピュータサイエンスのセクション全体があり、それ自体は印象的ですが、理論に興味がなくても、型システムを無視することは困難です。



2つの理由から、型システムに深く入り込みません。 第一に、私自身はこの分野を完全に理解していない、そして第二に、実際には、データ型間の関係を「感じる」ためにすべてを理解する必要はまったくありません。 インターフェイスのアーキテクチャに影響を与えるため、それらの動作を考慮することが重要であり、理論家としてではなく、実践者としてのタイピングについて説明します（美しいAPIを構築する例を使用）。



型システムには多くの特性がありますが、それらの間の最も重要な違いは、データ型を操作しようとしたときにデータ型がそれ自体について提供する情報の量です。



たとえば、Pythonを取り上げます。 タイプがあります。 ここに数字42があります。この数字にタイプを尋ねると、整数であると答えます。 これは包括的な情報であり、インタープリターは、整数が相互にやり取りできるルールのセットを定義できます。



ただし、Pythonには欠けているものが1つあります。複合データ型です。 Pythonのデータ型はすべてプリミティブです。つまり、特定の時点で、複合型とは異なり、そのうちの1つだけを操作できます。



ほとんどのプログラミング言語が持つ最も単純な複合データ型は構造です。 Pythonでは、多くの場合、ライブラリは独自の構造、たとえばDjangoのORMモデルやSQLAlchemyを定義する必要はありません。 データベースの各列は、構造内のフィールドに対応するPythonハンドルを介して表されます。主キーがidと呼ばれ、これがIntegerField（）であると言う場合、モデルを複合データ型として定義します。



複合型は構造のみに限定されません。 複数の番号を使用する必要がある場合は、コレクション（配列）を使用します。 Pythonにはこのためのリストがあり、リストの各要素は完全に任意のデータ型を持つことができます。これは、特定の要素型（整数のリストなど）を持つ他のプログラミング言語のリストとは異なります。



「整数リスト」というフレーズは、常に単なるリストよりも意味があります。 常にリストを調べて各要素のタイプを見ることができるので、これについて議論することができますが、空のリストをどうするか？ Pythonに空のリストがある場合、そのデータのタイプを判別できません。



値Noneを使用すると、同じ問題が発生します。 User引数を受け入れる関数があるとします。 Noneパラメータを渡した場合、それが「User」タイプのオブジェクトである必要があることは決してわかりません。



この問題の解決策は何ですか？ NULLポインターを持たず、明示的に指定された要素タイプを持つ配列を使用してください。 Haskellにはそれが存在することは誰もが知っていますが、開発者にとって敵対的ではない他の言語もあります。 たとえば、RustはC ++に非常に似ているため、私たちにとってより親しみやすいプログラミング言語です。 また、Rustには非常に強力な型システムがあります。



nullポインターが欠落している場合、「ユーザーが設定されていません」という値を渡すにはどうすればよいですか たとえば、Rustには、これにオプションのタイプがあります。 したがって、式Optionは（この場合は特定のユーザーの）値をラップするマークされた列挙であり、一部のユーザー（ユーザー）またはNoneを渡すことができることを意味します。 現在、変数には値がある場合とない場合があるため、この変数を使用するすべてのコードは、値Noneを渡す場合を正しく処理できる必要があります。そうでない場合は、コンパイルされません。

灰色の未来

以前は、動的型付けを使用した解釈言語と静的型付けを使用したコンパイル言語との間には明確な分離がありました。 新しいトレンドは、ゲームの現在のルールを変えています。



未知の領域に足を踏み入れた最初の兆候は、C＃言語の出現です。 これは静的型付けを備えたコンパイル言語であり、最初はJavaに非常に似ていました。 C＃言語が開発されると、そのタイプシステムに新しい機能が登場し始めました。 最も重要なイベントは、一般化された型の出現であり、コンパイラによって処理されなかったコレクション（リストおよび辞書）を厳密に典型化することができました。 さらに-その他：言語の作成者は、コードブロック全体の変数の静的な型付けを放棄する機能を導入しました。 これは、Webサービス（JSON、XMLなど）によって提供されるデータを操作する場合に非常に便利です。これは、潜在的に安全でない操作を実行し、型システムから例外をキャッチし、ユーザーに誤ったデータを通知できるためです。



現在、C＃言語型システムは非常に強力であり、共変および反変の仕様を持つジェネリック型をサポートしています。 また、nullポインターを許可する型の操作もサポートしています。 たとえば、nullとして表されるオブジェクトのデフォルト値を定義するために、null（ "??"）という値を持つ共用体演算子が追加されました。 C＃はすでにヌルを取り除くには行き過ぎていますが、すべてのボトルネックは制御されています。



静的型付けを備えた他のコンパイル言語も新しいアプローチを試みています。 そのため、C ++では常に静的型付けの言語でしたが、開発者は多くのレベルで型推論の実験を開始しました。 MyType <X、Y> :: const_iteratorの形式のイテレーターの時代は過去のものであり、現在ではほとんどすべての場合にオートタイプを使用でき、コンパイラーが目的のデータ型を代わりに使用します。



プログラミング言語Rustでは、型推論も非常にうまく実装されているため、変数の型をまったく指定せずに、静的型付けでプログラムを作成できます。

use std::collections::HashMap; fn main() { let mut m = HashMap::new(); m.insert("foo", vec!["some", "tags", "here"]); m.insert("bar", vec!["more", "here"]); for (key, values) in m.iter() { println!("{} = {}", key, values.connect("; ")); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

将来的には強力な型システムが出現すると信じています。 しかし、私の意見では、これは動的型付けの終わりには至らず、むしろ、これらのシステムは、ローカル型推論による静的型付けのパスに沿って発展するでしょう。

Pythonと明示的な型付け

少し前の会議で、誰かが静的型付けは素晴らしいと説得力を持って主張し、Pythonは本当にそれを必要としています。 この議論がどのように終わったか正確には覚えていませんが、結果はmypyプロジェクトであり、注釈構文と組み合わせて、Python 3のゴールドタイピング標準として提案されました。



この推奨事項を見たことがない場合は、次のソリューションを提供します。

 from typing import List def print_all_usernames(users: List[User]) -> None: for user in users: print(user.username)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは最善の解決策ではないと私は心から信じています。 多くの理由がありますが、主な問題は、残念ながらPythonの型システムがあまり良くないことです。 実際、言語の見方によって、言語のセマンティクスは異なります。



静的型付けを理解するには、型システムを適切に実装する必要があります。 2つのタイプがある場合、これらのタイプがどのように相互作用する必要があるかを常に知っている必要があります。 Pythonでは、これは当てはまりません。

Pythonタイプセマンティクス

スロットシステムに関する以前の記事を読んだ場合、Pythonの型は、実装されるレベル（CまたはPython）に応じて異なる動作をすることを覚えておく必要があります。 これは言語の非常に特殊な機能であり、他のどこにも表示されません。 同時に、開発の初期段階では、多くのプログラミング言語がインタープリターレベルで基本的なデータ型を実装しています。



Pythonには「基本的な」型はありませんが、Cにはデータ型のグループ全体が実装されています。これらはプリミティブ型および基本型であるだけでなく、ロジックのないものであれば何でもかまいません。 たとえば、collections.OrderedDictクラスはPythonで記述され、同じモジュールのcollections.defaultdictクラスはCで記述されています。



これは、可能な限り元の型をエミュレートする必要があるPyPyインタープリターに多くの問題を引き起こします。 これは、CPythonとの違いが目立たない優れたAPIを取得するために必要です。 Cで記述されたインタープリターレベルと他の言語との主な違いを理解することは非常に重要です。



別の例は、2.7より前のバージョンのPythonのreモジュールです。 それ以降のバージョンでは、完全に書き直されましたが、主な問題は依然として関連しています。インタープリターはプログラミング言語のように機能しません。



reモジュールには、正規表現をパターンにコンパイルするためのコンパイル機能があります。 この関数は文字列を受け取り、パターンオブジェクトを返します。 次のようになります。

 >>> re.compile('foobar') <_sre.SRE_Pattern object at 0x1089926b8>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パターンオブジェクトは_sreモジュールで定義されていることがわかります。_sreモジュールは内部モジュールですが、それでも利用可能です。

 >>> type(re.compile('foobar')) <type '_sre.SRE_Pattern'>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、_sreモジュールには実際にはこのオブジェクトが含まれていないため、これはそうではありません。

 >>> import _sre >>> _sre.SRE_Pattern Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'SRE_Pattern'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、これは型がその場所を私たちにだましている最初の時間ではなく、また、いずれにせよ内部型です。 先に進みます。 パターンのタイプ（_sre.SRE_Pattern）がわかっており、これはオブジェクトクラスの子孫です。

 >>> isinstance(re.compile(''), object) True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、すべてのオブジェクトが最も一般的なメソッドのいくつかを実装していることもわかっています。 たとえば、そのようなクラスのインスタンスには__repr__メソッドがあります。

 >>> re.compile('').__repr__() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: __repr__
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何が起こっているの？ 答えはまったく予想外です。 私には不明な理由で、バージョン2.7より前のPythonでは、SREパターンオブジェクトには独自のtp_getattrスロットがありました。 このスロットでは、独自の属性検索ロジックが実装され、独自の属性とメソッドへのアクセスが提供されました。 dir（）メソッドを使用してこのオブジェクトを調べると、多くのものが単に欠落していることがわかります。

 >>> dir(re.compile('')) ['__copy__', '__deepcopy__', 'findall', 'finditer', 'match', 'scanner', 'search', 'split', 'sub', 'subn']
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パターンオブジェクトの動作に関するこの小さな研究は、かなり予期しない結果につながります。 これが実際に起こることです。



データ型は、オブジェクトから継承することを宣言します。 これはCPythonには当てはまりますが、Python自体には当てはまりません。 Pythonレベルでは、この型はオブジェクト型のインターフェースに関連付けられていません。 Python言語を経由する呼び出しとは異なり、インタープリターを経由する呼び出しはすべて機能します。 したがって、たとえば、タイプ（x）は機能しますが、x .__ class__は機能しません。

サブクラスとは

上記の例は、Pythonには別のクラスを継承するクラスが存在する可能性があることを示していますが、同時にその動作は基本クラスに対応していません。 そして、静的型付けについて話している場合、これは重要な問題です。 そのため、Python 3では、Cで記述するまでdict型のインターフェイスを実装できません。この制限の理由は、この型は単に実装できない可視オブジェクトに対する動作を決定するためです。 これは不可能です。



したがって、型注釈を適用し、関数が文字列としてキーを持ち、引数として整数値を持つ辞書を受け入れることを宣言すると、この関数が辞書、または辞書動作を持つオブジェクトを受け入れるかどうかを注釈から判断することはできません辞書のサブクラスを渡します。

未定義の動作

正規表現パターンオブジェクトの奇妙な動作はPython 2.7で変更されましたが、問題は残りました。 辞書の例で示されたように、コードの記述方法に応じて言語の動作が異なり、型システムの正確なセマンティクスを完全に理解することは不可能です。



クラスインスタンスのタイプを比較すると、Pythonの2番目のバージョンのインタープリターの内部の非常に奇妙な動作が見られます。 3番目のバージョンでは、インターフェースが変更され、この動作はもはや彼女には関係ありませんが、根本的な問題は依然として多くのレベルで検出できます。



例としてセットの並べ替えを見てみましょう。 Pythonセットは非常に便利なデータ型ですが、比較すると非常に奇妙な動作をします。 Python 2には、引数として2つのオブジェクトを受け取り、渡された引数のどちらが大きいかを示す数値を返すcmp（）関数があります。



セットオブジェクトの2つのインスタンスを比較しようとすると、次のようになります。

 >>> cmp(set(), set()) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot compare sets using cmp()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜそう 正直に言うと、私にはわからない。 おそらく理由は、比較演算子がセットでどのように機能するかであり、これはcmp（）では機能しません。 同時に、frozensetsのインスタンスは著しく比較されます：

 >>> cmp(frozenset(), frozenset()) 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのセットの1つが空でない場合を除き、再び例外が発生します。 なんで？ 答えは簡単です。これはCPythonインタープリターの最適化であり、Pythonの動作ではありません。 空のfrozensetは常に同じ値を持ち（不変の型であり、要素を追加することはできません）、したがって常に同じオブジェクトです。 2つのオブジェクトのメモリ内のアドレスが同じである場合、cmp（）関数はすぐに0を返します。これがなぜ起こるのか、Python 2の比較関数のコードは複雑すぎてわかりにくいため、すぐにはわかりませんが、この関数にはいくつかの方法があります。この結果につながる可能性があります。



ポイントは、それがバグであることだけではありません。 ポイントは、Pythonでは型同士の相互作用の原理を明確に理解していないということです。 代わりに、Pythonの型システムのすべての動作に対する回答が常に1つありました。「CPythonはこのように機能します」。



PyPyがCPythonの動作を再構築するために行った作業量を過大評価することは困難です。 PyPyがPythonで書かれているとすると、興味深い問題が浮かび上がります。 Pythonプログラミング言語が、言語の現在のPython部分の実装方法で記述されていれば、PyPyの問題ははるかに少なくなります。

インスタンスレベルの動作

仮に、説明したすべての問題が修正されたバージョンのPythonがあると想像してみましょう。 この場合でも、静的型を言語に追加することはできません。 その理由は、Pythonレベルでは、型は重要な役割を果たさず、さらに重要なのは、オブジェクトが互いにどのように相互作用するかです。



たとえば、日時オブジェクトは一般に他のオブジェクトと比較できます。 ただし、2つのdatetimeオブジェクトを互いに比較する場合、タイムゾーンに互換性がある場合にのみこれを実行できます。 また、多くの操作の結果は、それらに関係するオブジェクトを慎重に調べるまで予測できない場合があります。 Python 2で2つの文字列を連結した結果は、Unicodeまたはバイト文字列になります。 コーデックシステムの異なるエンコードまたはデコードAPIは、異なるオブジェクトを返す場合があります。



言語としてのPythonは、型注釈がうまく機能するには動的すぎます。 言語でジェネレータが果たす重要な役割を想像してみてください。それでも、各反復で多くの型変換操作を実行できます。



型注釈の導入により、せいぜいあいまいな効果が生まれます。 ただし、これがAPIのアーキテクチャに悪影響を与える可能性が高くなります。 少なくとも、これらの注釈がプログラムの起動前に切り取られない場合、コードの実行が遅くなります。 型注釈は、PythonをPythonでは不可能なものに変えることなく、効率的な静的コンパイルを許可しません。

手荷物とセマンティクス

Pythonに対する私の個人的な否定的な態度は、この言語が到達した不条理な複雑さによるものだと思います。 それは単に仕様に欠けているだけであり、今日、型間の相互作用は非常に複雑になり、すべてを理解することはできないかもしれません。 非常に多くの松葉杖とこれらの小さな動作機能がすべてあるため、今日可能な言語仕様はCPythonインタープリターの詳細な説明だけです。



私の意見では、上記のすべてを考慮すると、型注釈の導入はほとんど意味がありません。



将来、誰かが主に動的な型付けを使用して新しいプログラミング言語を開発したい場合は、型システムがどのように機能するかについての明確な説明にさらに時間を費やす必要があります。 これはJavaScriptで非常にうまく行われ、組み込み型のすべてのセマンティクスは、意味をなさない場合でも詳細に記述されます。これは私の意見では良い習慣です。 言語のセマンティクスがどのように機能するかを明確に定義しておけば、将来、インタープリターの速度を最適化したり、オプションの静的型付けを追加したりすることも簡単になります。



バランスのとれた、十分に文書化された言語アーキテクチャを維持すると、多くの問題を回避できます。 将来のプログラミング言語のアーキテクトは、言語の振る舞いが最終的にインタープリターの振る舞いによって説明されるとき、PHP、Python、およびRubyの言語の開発者が犯したすべての間違いを絶対に避けるべきです。



Pythonがより良い方向に変わることはまずないと思います。 この困難な遺産をすべて取り除くには、時間と労力がかかりすぎます。



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