Pythonにはまだ4つの強力な機能がありません

Pythonは生きた言語であり、時代に対応するために絶えず開発されています。Python Software Foundationは、標準ライブラリとリファレンス実装CPythonに追加を行うだけでなく、言語自体に新しい機能と改良を導入しています。

たとえば、Python 3.8では、インライン割り当ての新しい構文(「セイウチ演算子」)が導入され、特定の操作がより簡潔になりました。もう1つの新しく承認された構文の改善であるパターンマッチングにより、考えられる多くのケースの1つを評価するコードを簡単に記述できるようになります。これらの機能は両方とも、他の言語での存在と有用性に触発されました。

そして、それらは、Pythonに追加して、言語をより表現力豊かで、より強力で、現代のプログラミングの世界により適したものにすることができる、数多くの便利な機能の2つにすぎません。他に何を望みますか?Pythonに真の価値を追加できる言語機能がさらに4つあります。2つは実際に取得できる可能性があり、2つはおそらく取得しない可能性があります。 

真の定数

Pythonには、実際には定数値の概念がありません。今日、Pythonの定数はほとんど慣例の問題です。オールキャップスとスネークケースの名前を使用することDO_NOT_RESTART は、たとえば、変数が定数であることを意図していることを示唆しています。同様に、 typing.Final 型注釈は、オブジェクトを変更してはならないというヒントをリンターに提供しますが、実行時にそれを強制することはありません。

どうして?なぜなら、可変性はPythonの動作に深く根付いているからです。変数に値を割り当てると(たとえば)  x=3 、ローカル名前空間に名前を作成し x、整数値を持つシステム内のオブジェクトをポイントします 3。 Pythonは常に、名前は変更可能であると想定しています—任意の名前が任意のオブジェクトを指す可能性があることを前提としています。つまり、名前が使用されるたびに、Pythonはそれが指しているオブジェクトを検索するという問題に直面します。このダイナミズムは、Pythonの実行が他のいくつかの言語よりも遅い主な理由の1つです。 Pythonのダイナミズムは、優れた柔軟性と利便性を提供しますが、実行時のパフォーマンスが犠牲になります。

Pythonで真の定数宣言を使用する利点の1つは、実行時に行われるオブジェクトルックアップの頻度がいくらか減少し、パフォーマンスが向上することです。ランタイムは、特定の値が決して変更されないことを事前に知っている場合、そのバインディングを検索する必要はありません。これは、Pythonアプリ(Cython、Nuitka)からマシンネイティブコードを生成するシステムなど、サードパーティによるさらなる最適化の手段を提供する可能性もあります。

ただし、真の定数は大きな変更であり、おそらく後方互換性のない変更です。また、定数が新しい構文(たとえば、まだ使用されていない$ シンボル)を介して、またはPythonの既存の名前宣言方法の拡張として提供されるかどうかについても議論の余地があります 。最後に、ダイナミズムが魅力の大部分を占める言語で真の定数が意味をなすかどうかという、より大きな哲学的な問題があります。

要するに、Pythonで真の定数が表示される可能性はありますが、それは大きな重大な変更になるでしょう。

真のオーバーロードとジェネリック

多くの言語では、同じ関数の複数のバージョンを記述して、さまざまな種類の入力を処理できます。たとえば、 to_string() 関数には、整数、浮動小数点数、またはその他のオブジェクトから変換するためのさまざまな実装がありますが、便宜上、同じ名前を共有します。「オーバーロード」または「ジェネリック」を使用すると、特定のタイプ専用のメソッドを使用するのではなく、一般的なプロセスのジェネリックメソッドを記述できるため、堅牢なソフトウェアを簡単に記述できます。

Pythonでは、1つの関数名を使用して多くの作業を実行できますが、関数の複数のインスタンスを定義することはできません。特定のスコープで名前を定義し、一度に1つのオブジェクトにのみバインドできるため、同じ名前で1つの関数の複数のバージョンを使用することはできません。

Python開発者がこれを回避するために通常行うことは 、関数に送信される変数のタイプを決定するために、isinstance() またはの ような組み込みを使用 type()して、タイプに基づいてアクションを実行することです。これには、内部で関数のタイプ固有のバージョンへのディスパッチが含まれる場合があります。ただし、このアプローチでは、拡張可能にするために邪魔にならない限り、他の開発者が関数を拡張することは困難です。たとえば、サブクラス化できるクラス内のメソッドにディスパッチすることによってです。

2007年4月に進められたPEP3124は、関数が過負荷になる可能性があることを示すために関数を装飾するメカニズムを提案しました。提案は完全に却下されるのではなく延期されました。つまり、アイデアは基本的に健全でしたが、それを実装する時期は適切ではありませんでした。Pythonでのオーバーロードの採用を加速する、またはアイデアを完全に捨てる原因となる可能性がある1つの要因は、新しく提案されたパターンマッチングシステムの実装です。

理論的には、パターンマッチングを内部で使用して、過負荷のディスパッチを処理できます。ただし、パターンマッチングは、型シグネチャに基づいて操作をディスパッチするための洗練された方法をすでに提供しているため、Pythonでジェネリックを実装しない理由として指定することもできます。

そのため、ある日Pythonで真のオーバーロードが発生するか、その利点が他のメカニズムに取って代わられる可能性があります。

末尾再帰の最適化

多くの言語コンパイラは末尾再帰の最適化を採用しています。この最適化では、自身を呼び出す関数がアプリケーションに新しいスタックフレームを作成しないため、実行時間が長すぎるとスタックが爆発するリスクがあります。Pythonはこれを行いません。実際、Pythonの作成者は一貫してそうすることに反対しています。

1つの理由は、Pythonの多くが、 ジェネレーターやコルーチンなど、再帰 ではなく 反復を使用 していることです。この場合、再帰的なメカニズムの代わりに、ループとスタック構造を持つ関数を使用することを意味します。ループの各呼び出しをスタックに保存して新しい再帰を作成し、再帰が終了するとスタックからポップすることができます。

Python開発者は、再帰の代わりにこれらのパターンを使用することをお勧めします。そのため、再帰の最適化にはほとんど期待が持てないようです。Pythonのイディオムは他のソリューションをサポートしているため、ここでの可能性はまったくありません。

マルチラインラムダ

ラムダ、つまり無名関数は、言語作成者のGuido van Rossumが抵抗した後、Pythonになりました。Pythonラムダは現在存在しているため、非常に制約があります。関数本体として使用できるのは、単一の式(基本的に、代入演算の等号の右側にあるもの)のみです。ステートメントの完全なブロックが必要な場合は、それらを分割して、それらから実際の関数を作成します。

その理由は、ヴァン・ロッサムが見ている言語のデザインにあります。バン・ロッサムが2006年に書いたように、「私は見つける 任意の 式の途中でインデントベースのブロックを埋め込み、容認できないソリューションを。ステートメントグループ化の代替構文(中括弧やbegin / endキーワードなど)も同様に受け入れられないため、これにより、複数行のラムダが解決できないパズルになります。」

言い換えれば、問題は技術的なものではありませんが、Python構文の既存の美学を補完する複数行ラムダの構文の欠如です。特別なケースを作成することを伴わない方法はおそらくありませんし、特別なケースが発生する言語は使用するのが不快になる傾向があります。そのようなユニコーンが現れるまでは、別々に定義された関数を使用する必要があります。

複数行のラムダはおそらくPythonでは発生していません。

Pythonについてもっと読む:

  • Python 3.9:新機能と優れた機能
  • Python3.8の最高の新機能
  • PoetryによるPythonプロジェクト管理の改善
  • Virtualenvとvenv:Python仮想環境の説明
  • Pythonvirtualenvとvenvはすべきこととすべきでないこと
  • Pythonのスレッド化とサブプロセスの説明
  • Pythonデバッガーの使用方法
  • timeitを使用してPythonコードをプロファイリングする方法
  • cProfileを使用してPythonコードをプロファイリングする方法
  • Pythonで非同期を始めましょう
  • Pythonでasyncioを使用する方法
  • PythonをJavaScriptに変換する方法(そしてまた元に戻す方法)
  • Python 2 EOL:Python2の終わりを乗り切る方法
  • プログラミングのニーズごとに12個のPython
  • すべてのPython開発者向けの24のPythonライブラリ
  • あなたが見逃したかもしれない7つの甘いPythonIDE
  • Pythonの3つの主な欠点とその解決策
  • 13のPythonWebフレームワークを比較
  • バグを粉砕するための4つのPythonテストフレームワーク
  • 見逃したくない6つの優れたPython機能
  • 機械学習をマスターするための5つのPythonディストリビューション
  • 自然言語処理のための8つの優れたPythonライブラリ
  • 並列処理用の6つのPythonライブラリ
  • PyPyとは何ですか?痛みのない高速Python
  • Cythonとは何ですか?Cの速度でのPython