Python 2.1の新機能—Pythonドキュメント

提供：Dev Guides
< PythonPython/docs/3.8/whatsnew/2.1
移動先:案内、検索

Python2.1の新機能

著者
午前 Kuchling

序章

この記事では、Python2.1の新機能について説明します。 2.1ではPython2.0ほど多くの変更はありませんが、それでもいくつかの嬉しい驚きがあります。 2.1は、Python拡張プロポーザル（PEP）を使用して操作される最初のリリースであるため、大規模な変更のほとんどには、より完全なドキュメントと変更の設計根拠を提供するPEPが付属しています。 この記事では、新機能を完全に文書化しようとはしていませんが、Pythonプログラマー向けの新機能の概要を説明しているだけです。 特に関心のある新機能の詳細については、Python2.1のドキュメントまたは特定のPEPを参照してください。

Python開発チームの最近の目標の1つは、新しいリリースのペースを加速することであり、新しいリリースは6〜9か月ごとにリリースされます。 2.1は、この速いペースでリリースされた最初のリリースであり、最初のアルファ版は、2.0の最終バージョンがリリースされてから3か月後の1月に登場します。

Python 2.1の最終リリースは、2001年4月17日に行われました。


PEP 227：ネストされたスコープ

Python 2.1での最大の変更は、Pythonのスコープルールです。 Python 2.0では、変数名の検索に使用される名前空間は、ローカル、モジュールレベル、および組み込みの名前空間の最大3つです。 それは彼らの直感的な期待と一致しなかったので、これはしばしば人々を驚かせました。 たとえば、ネストされた再帰関数定義は機能しません。 

def f():
    ...
    def g(value):
        ...
        return g(value-1) + 1
    ...

名前gのバインディングがローカル名前空間にもモジュールレベルの名前空間にもないため、関数g()は常に NameError 例外を発生させます。 これは実際にはそれほど問題ではありませんが（このような内部関数を再帰的に定義する頻度はどれくらいですか？）、これも lambda 式を使用して不器用になり、これは実際には問題でした。 lambda を使用するコードでは、引数のデフォルト値としてローカル変数を渡すことで、コピーされているローカル変数を見つけることができます。 

def find(self, name):
    "Return list of any entries equal to 'name'"
    L = filter(lambda x, name=name: x == name,
               self.list_attribute)
    return L

その結果、強力に機能するスタイルで記述されたPythonコードの可読性が大幅に低下します。

Python 2.1の最も重要な変更は、この問題を修正するために静的スコープが言語に追加されたことです。 最初の効果として、上記の例ではname=nameのデフォルト引数は不要になりました。 簡単に言えば、指定された変数名に関数内の値が割り当てられていない場合（割り当て、または def 、 class 、または import ステートメントによって）、変数への参照は、囲んでいるスコープのローカル名前空間で検索されます。 ルールのより詳細な説明と実装の詳細は、PEPにあります。

この変更により、モジュールレベルと、さらに関数定義を含む関数内のローカル変数の両方で同じ変数名が使用されているコードで、互換性の問題が発生する可能性があります。 そもそもそのようなコードを読むのはかなり混乱していたので、これはかなりありそうもないようです。

この変更の副作用の1つは、from module import *およびexecステートメントが特定の条件下で関数スコープ内で不正にされることです。 Pythonリファレンスマニュアルには、from module import *はモジュールのトップレベルでのみ有効であるとずっと書かれていますが、CPythonインタープリターはこれまでこれを強制したことはありません。 ネストされたスコープの実装の一部として、Pythonソースをバイトコードに変換するコンパイラは、含まれているスコープ内の変数にアクセスするために異なるコードを生成する必要があります。 from module import *およびexecは、コンパイル時に認識できない名前をローカル名前空間に追加するため、コンパイラーがこれを理解することを不可能にします。 したがって、関数に関数定義または自由変数を含む lambda 式が含まれている場合、コンパイラーは SyntaxError 例外を発生させることでこれにフラグを立てます。

上記の説明をもう少し明確にするために、次に例を示します。 

x = 1
def f():
    # The next line is a syntax error
    exec 'x=2'
    def g():
        return x

execステートメントを含む4行目は構文エラーです。これは、execがxという名前の新しいローカル変数を定義し、その値にg()がアクセスする必要があるためです。

execはほとんどのPythonコードで使用されることはめったにないため、これはそれほど制限にはなりません（使用されると、とにかく設計が不十分であることを示していることがよくあります）。

互換性の懸念により、ネストされたスコープが徐々に導入されています。 Python 2.1では、デフォルトでは有効になっていませんが、 PEP 236 で説明されているように、futureステートメントを使用してモジュール内で有効にすることができます。 （ PEP 236 の詳細については、次のセクションを参照してください。）Python 2.2では、ネストされたスコープがデフォルトになり、オフにする方法はありませんが、ユーザーはそれらの導入に起因する破損を修正するために、2.1のすべての寿命がありました。

も参照してください

PEP 227 -静的にネストされたスコープ
Jeremy Hyltonによって書かれ、実装されました。


PEP 236：__ future__ディレクティブ

ネストされたスコープへの反応は、2.1リリースでコードを壊す危険性についての広範な懸念であり、Pythoneersにもっと保守的なアプローチをとらせるのに十分なほど強力でした。 このアプローチは、リリースN +1で必須となるリリースNでオプション機能を有効にするための規則を導入することで構成されます。

構文は、予約済みモジュール名 __ future __ を使用するfrom...importステートメントを使用します。 ネストされたスコープは、次のステートメントで有効にできます。 

from __future__ import nested_scopes

通常の import ステートメントのように見えますが、そうではありません。 そのような将来の声明をどこに置くことができるかについての厳格な規則があります。 これらはモジュールの先頭にのみ配置でき、Pythonコードまたは通常のimportステートメントの前に配置する必要があります。 これは、このようなステートメントがPythonバイトコードコンパイラがコードを解析してバイトコードを生成する方法に影響を与える可能性があるため、バイトコードが生成されるステートメントの前に置く必要があるためです。

も参照してください

PEP 236 - __ future __ に戻る
Tim Petersによって書かれ、主にJeremyHyltonによって実装されました。


PEP 207：豊富な比較

以前のバージョンでは、ユーザー定義クラスと拡張タイプの比較を実装するためのPythonのサポートは非常に単純でした。 クラスは、クラスの2つのインスタンスが与えられた__cmp__()メソッドを実装でき、等しい場合は0を返し、等しくない場合は+1または-1を返すことができました。 このメソッドは、例外を発生させたり、ブール値以外のものを返したりすることはできませんでした。 数値Pythonのユーザーは、このモデルが弱すぎて制限的であることに気付くことがよくあります。数値Pythonが使用される数値計算プログラムでは、2つの行列の要素ごとの比較を実行して、次の結果を含む行列を返すことができると便利だからです。各要素の特定の比較。 2つの行列のサイズが異なる場合、比較はエラーを通知するために例外を発生させることができなければなりません。

Python 2.1では、このニーズをサポートするために豊富な比較が追加されました。 Pythonクラスは、<、<=、>、>=、==、および [X120Xのそれぞれを個別にオーバーロードできるようになりました。 ] オペレーション。 新しいマジックメソッドの名前は次のとおりです。

手術 メソッド名
< __lt__()
<= __le__()
> __gt__()
>= __ge__()
== __eq__()
!= __ne__()

（マジックメソッドは、対応するFortran演算子.LT.にちなんで名付けられています。 .LE.、 ＆NS。 数値プログラマーはほぼ間違いなくこれらの名前に精通しており、覚えやすいでしょう。）

これらの各マジックメソッドはmethod(self, other)の形式であり、selfは演算子の左側のオブジェクトになり、otherは右側。 たとえば、式A < Bを指定すると、A.__lt__(B)が呼び出されます。

これらの魔法のメソッドはそれぞれ、ブール値、行列、リスト、その他のPythonオブジェクトなど、何でも返すことができます。 あるいは、比較が不可能、一貫性がない、またはその他の意味がない場合は、例外を発生させることができます。

組み込みのcmp(A,B)関数は、豊富な比較機構を使用でき、使用する比較演算を指定するオプションの引数を受け入れるようになりました。 これは、文字列"<"、"<="、">"、">="、"=="、または"!="のいずれかとして指定されます。 。 オプションの3番目の引数なしで呼び出された場合、cmp()は、以前のバージョンのPythonと同様に、-1、0、または+1のみを返します。 それ以外の場合は、適切なメソッドを呼び出し、任意のPythonオブジェクトを返すことができます。

Cプログラマーにとっても対応する関心のある変更があります。 型オブジェクトに新しいスロットtp_richcmpがあり、特定の豊富な比較を実行するためのAPIがあります。 ここではCAPIについては説明しませんが、関連する関数の完全なリストについては、 PEP 207 または2.1のCAPIドキュメントを参照してください。

も参照してください

PEP 207 -豊富な比較
Guido van Rossumによって書かれ、David Ascherによる以前の作業に大きく基づいており、Guido vanRossumによって実装されています。


PEP 230：警告フレームワーク

Pythonは、その10年間の存在の中で、その過程で一定数の廃止されたモジュールと機能を蓄積してきました。 機能が安全に削除できる時期を知ることは困難です。コードがそれをどれだけ使用しているかを知る方法がないためです。おそらく、機能に依存するプログラムはないか、多くの人が依存しています。 より構造化された方法で古い機能を削除できるようにするために、警告フレームワークが追加されました。 Python開発者が機能を削除したい場合、Pythonの次のバージョンで最初に警告がトリガーされます。 次のPythonバージョンでは機能を削除でき、ユーザーは古い機能の使用を削除するための完全なリリースサイクルがあります。

Python 2.1は、このスキームで使用される警告フレームワークを追加します。 警告を発行し、表示したくない警告を除外する機能を提供する警告モジュールを追加します。 サードパーティのモジュールもこのフレームワークを使用して、サポートする必要がなくなった古い機能を廃止することができます。

たとえば、Python 2.1では、regexモジュールは非推奨であるため、インポートすると警告が出力されます。 

>>> import regex
__main__:1: DeprecationWarning: the regex module
         is deprecated; please use the re module
>>>

警告は、 warnings.warn（）関数を呼び出すことで発行できます。 

warnings.warn("feature X no longer supported")

最初のパラメータは警告メッセージです。 追加のオプションパラメータを使用して、特定の警告カテゴリを指定できます。

フィルタを追加して、特定の警告を無効にすることができます。 警告を抑制するために、メッセージまたはモジュール名に正規表現パターンを適用できます。 たとえば、regexモジュールを使用するプログラムがあり、今すぐ re モジュールを使用するように変換する時間を割いたくない場合があります。 を呼び出すことで警告を抑制できます 

import warnings
warnings.filterwarnings(action = 'ignore',
                        message='.*regex module is deprecated',
                        category=DeprecationWarning,
                        module = '__main__')

これにより、 __ main __ モジュールでトリガーされたクラス DeprecationWarning の警告にのみ適用されるフィルターが追加され、regexに関するメッセージにのみ一致する正規表現が適用されます。モジュールは非推奨になり、そのような警告は無視されます。 警告は、1回だけ出力したり、問題のあるコードが実行されるたびに出力したり、プログラムを停止させる例外に変換したりすることもできます（もちろん、例外が通常の方法でキャッチされない限り）。

警告を発行するための関数もPythonのCAPIに追加されました。 詳細については、PEP230またはPythonのAPIドキュメントを参照してください。

も参照してください

PEP 5 -言語進化のガイドライン
Pythonから古い機能を削除するときに従うべき手順を指定するためにPaulPrescodによって書かれました。 このPEPに記載されているポリシーは正式には採用されていませんが、最終的なポリシーはPrescodの提案とそれほど変わらないでしょう。
PEP 230 -警告フレームワーク
グイドヴァンロッサムによって書かれ、実装されています。


PEP 229：新しいビルドシステム

Pythonをコンパイルするとき、ユーザーはさまざまな追加モジュールを有効にするために、Modules/Setupファイルにアクセスして編集する必要がありました。 デフォルトのセットは比較的小さく、ほとんどのUnixプラットフォームでコンパイルされるモジュールに制限されています。 つまり、より多くの機能を備えたUnixプラットフォーム、特にLinuxでは、Pythonのインストールに役立つモジュールがすべて含まれているとは限りません。

Python 2.0は、拡張機能を配布およびインストールするためのモジュールのセットであるDistutilsを追加しました。 Python 2.1では、Distutilsを使用して拡張モジュールの標準ライブラリの多くをコンパイルし、現在のマシンでサポートされているものを自動検出します。 これにより、Pythonのインストールがより簡単で機能的になることが期待されています。

モジュールを有効にするためにModules/Setupファイルを編集する代わりに、Pythonソースディストリビューションのトップディレクトリにあるsetup.pyスクリプトがビルド時に実行され、どのモジュールが可能かを検出しようとします。システム上のモジュールとヘッダーファイルを調べることで有効になります。 モジュールがModules/Setupで構成されている場合、setup.pyスクリプトはそのモジュールをコンパイルしようとせず、Modules/Setupファイルの内容に従います。 これにより、特定のプラットフォームに必要な奇妙なコマンドラインフラグまたはライブラリを特定する方法が提供されます。

ビルドメカニズムに対する別の広範囲にわたる変更で、Neil Schemenauerは物事を再構築し、PythonがトップディレクトリとPython/、Parser/、Objects/、およびModules/サブディレクトリ。 これにより、Pythonの構築が高速になり、Makefileのハッキングがより明確かつ簡単になります。

も参照してください

PEP 229 -Distutilsを使用してPythonを構築する
AMによって書かれ、実装されています Kuchling。


PEP 205：弱参照

weakref モジュールから入手できる弱参照は、Pythonプログラマーのツールボックスにあるマイナーですが便利な新しいデータ型です。

オブジェクトへの参照を（たとえば、辞書やリストに）保存すると、そのオブジェクトを永久に存続させるという副作用があります。 この動作が望ましくない特定のケースがいくつかあります。オブジェクトキャッシュが最も一般的なケースであり、別のケースはツリーなどのデータ構造の循環参照です。

たとえば、関数の引数とその結果を辞書に格納することにより、別の関数f(x)の結果をキャッシュするメモ化関数について考えてみます。 

_cache = {}
def memoize(x):
    if _cache.has_key(x):
        return _cache[x]

    retval = f(x)

    # Cache the returned object
    _cache[x] = retval

    return retval

このバージョンは整数などの単純なもので機能しますが、副作用があります。 _cacheディクショナリは戻り値への参照を保持しているため、Pythonプロセスが終了してクリーンアップするまで、戻り値の割り当てが解除されることはありません。 これは整数ではあまり目立ちませんが、f()がオブジェクト、または大量のメモリを消費するデータ構造を返す場合、これは問題になる可能性があります。

弱参照は、オブジェクトをその時間を超えて存続させないキャッシュを実装する方法を提供します。 弱参照を介してのみオブジェクトにアクセスできる場合、オブジェクトの割り当てが解除され、弱参照は、参照したオブジェクトが存在しなくなったことを示します。 オブジェクト obj への弱参照は、wr = weakref.ref(obj)を呼び出すことによって作成されます。 参照されているオブジェクトは、弱参照を関数であるかのように呼び出すことによって返されます：wr()。 参照されているオブジェクトを返します。オブジェクトが存在しない場合はNoneを返します。

これにより、弱い参照をキャッシュに格納することにより、キャッシュがオブジェクトを存続させないmemoize()関数を作成できます。 

_cache = {}
def memoize(x):
    if _cache.has_key(x):
        obj = _cache[x]()
        # If weak reference object still exists,
        # return it
        if obj is not None: return obj

    retval = f(x)

    # Cache a weak reference
    _cache[x] = weakref.ref(retval)

    return retval

weakref モジュールでは、弱参照のように動作するプロキシオブジェクトを作成することもできます。つまり、プロキシオブジェクトによってのみ参照されるオブジェクトの割り当てが解除されますが、オブジェクトを取得するために明示的な呼び出しを要求する代わりに、プロキシはすべての操作を透過的に転送します。オブジェクトがまだ存在する限り、オブジェクト。 オブジェクトの割り当てが解除されている場合、プロキシを使用しようとすると、weakref.ReferenceError例外が発生します。 

proxy = weakref.proxy(obj)
proxy.attr   # Equivalent to obj.attr
proxy.meth() # Equivalent to obj.meth()
del obj
proxy.attr   # raises weakref.ReferenceError

も参照してください

PEP 205 -弱い参照
フレッドLによって書かれ、実装されています。 ドレイクジュニア


PEP 232：関数属性

Python 2.1では、関数に任意の情報を添付できるようになりました。 __doc__属性が関数に情報を添付する唯一の方法であったため、人々は関数とメソッドに関する情報を保持するためにdocstringを使用することがよくありました。 たとえば、Zope Webアプリケーションサーバーでは、関数はdocstringを持つことでパブリックアクセスに対して安全であるとマークされ、John AycockのSPARK解析フレームワークでは、docstringは解析されるBNF文法の一部を保持します。 docstringは実際には関数のドキュメントを保持することを目的としているため、このオーバーロードは残念です。 たとえば、Zopeでの私的使用を目的とした関数を適切に文書化できないことを意味します。

通常のPython構文を使用して、関数で任意の属性を設定および取得できるようになりました。 

def f(): pass

f.publish = 1
f.secure = 1
f.grammar = "A ::= B (C D)*"

属性を含む辞書には、関数の __ dict __ としてアクセスできます。 クラスインスタンスの __ dict __ 属性とは異なり、関数では実際に新しい辞書を __ dict __ に割り当てることができますが、新しい値は通常のPython辞書に制限されています。 トリッキーにUserDictインスタンス、またはマッピングのように動作するその他のランダムオブジェクトに設定することはできません。

も参照してください

PEP 232 -関数属性
バリーワルシャワによって書かれ、実装されています。


PEP 235：大文字と小文字を区別しないプラットフォームでのモジュールのインポート

一部のオペレーティングシステムには、大文字と小文字を区別しないファイルシステムがあり、MacOSとWindowsが主な例です。 これらのシステムでは、ファイル名FILE.PYとfile.pyを区別することはできませんが、ファイル名は元の大文字と小文字が区別されます（大文字と小文字は区別されます）。

Python 2.1では、 import ステートメントは、大文字と小文字を区別しないプラットフォームで大文字と小文字を区別することをシミュレートするために機能します。 Pythonはデフォルトで最初の大文字と小文字を区別する一致を検索し、そのようなファイルが見つからない場合は ImportError を発生させるため、import fileはFILE.PYという名前のモジュールをインポートしません。 Pythonインタープリターを起動する前に、 PYTHONCASEOK 環境変数を設定することで、大文字と小文字を区別しないマッチングを要求できます。


PEP 217：インタラクティブディスプレイフック

Pythonインタープリターをインタラクティブに使用する場合、コマンドの出力は、組み込みの repr（）関数を使用して表示されます。 Python 2.1では、変数 sys.displayhook（）を、 repr（）の代わりに呼び出される呼び出し可能オブジェクトに設定できます。 たとえば、特別なきれいな印刷機能に設定できます。 

>>> # Create a recursive data structure
... L = [1,2,3]
>>> L.append(L)
>>> L # Show Python's default output
[1, 2, 3, [...]]
>>> # Use pprint.pprint() as the display function
... import sys, pprint
>>> sys.displayhook = pprint.pprint
>>> L
[1, 2, 3,  <Recursion on list with id=135143996>]
>>>

も参照してください

PEP 217 -インタラクティブに使用するためのディスプレイフック
Moshe Zadkaによって書かれ、実装されました。


PEP 208：新しい強制モデル

経営幹部レベルでの数値強制の実行方法が大幅に変更されました。 これはPythonのC拡張機能の作成者にのみ影響し、数値演算をサポートする拡張機能タイプをより柔軟に記述できるようになります。

拡張タイプは、PyTypeObject構造体にタイプフラグPy_TPFLAGS_CHECKTYPESを設定して、新しい強制モデルをサポートしていることを示すことができるようになりました。 このような拡張タイプでは、数値スロット関数は、同じタイプの2つの引数が渡されると想定できなくなりました。 代わりに、タイプの異なる2つの引数を渡して、独自の内部強制を実行できます。 スロット関数に処理できないタイプが渡された場合、Py_NotImplementedシングルトン値への参照を返すことにより、失敗を示すことができます。 次に、他のタイプの数値関数が試され、おそらくそれらは操作を処理できます。 他のタイプもPy_NotImplementedを返す場合、 TypeError が発生します。 Pythonで記述された数値メソッドは、Py_NotImplementedを返すこともでき、インタプリタはメソッドが存在しないかのように動作します（おそらく、 TypeError を発生させ、別のオブジェクトの数値メソッドを試行します）。

も参照してください

PEP 208 -強制モデルの作り直し
Neil Schemenauerによって書かれ、実装されました。これは、Marc-AndréLemburgによる以前の作業に大きく基づいています。 これを読んで、数値演算が経営幹部レベルでどのように処理されるかについての細かい点を理解してください。


PEP 241：Pythonパッケージのメタデータ

Pythonユーザーからの一般的な不満は、存在するすべてのPythonモジュールの単一のカタログがないことです。 NS。 http://www.vex.net/parnassus/にあるMiddletonのVaultsof Parnassusは、Pythonモジュールの最大のカタログですが、Vaultsでのソフトウェアの登録はオプションであり、多くの人は気にしません。

問題を修正するための最初の小さなステップとして、Distutils sdist コマンドを使用してパッケージ化されたPythonソフトウェアには、名前、バージョン、作成者などのパッケージに関する情報を含むPKG-INFOという名前のファイルが含まれます（メタデータ、カタログ用語で）。 PEP 241 には、PKG-INFOファイルに存在する可能性のあるフィールドの完全なリストが含まれています。 人々がPython2.1を使用してソフトウェアをパッケージ化し始めると、ますます多くのパッケージにメタデータが含まれるようになり、自動カタログシステムを構築してそれらを試すことが可能になります。 結果の経験により、本当に優れたカタログを設計し、そのサポートをPython2.2に組み込むことができるかもしれません。 たとえば、Distutils sdist および bdist _ * コマンドは、パッケージをカタログサーバーに自動的にアップロードするuploadオプションをサポートできます。

以前のPythonバージョンのユーザー向けにDistutilsの新しいリリースが作成されるため、Python 2.1を使用していない場合でも、PKG-INFOを含むパッケージの作成を開始できます。 Distutilsのバージョン1.0.2には、 PEP 241 で説明されている変更と、さまざまなバグ修正および機能拡張が含まれています。 これは、 https://www.python.org/community/sigs/current/distutils-sig/のDistutilsSIGから入手できます。

も参照してください

PEP 241 -Pythonソフトウェアパッケージのメタデータ
AMによって書かれ、実装されています Kuchling。
PEP 243 -モジュールリポジトリのアップロードメカニズム
Sean Reifschneiderによって書かれたこのドラフトPEPは、Pythonパッケージを中央サーバーにアップロードするために提案されたメカニズムについて説明しています。


新規および改善されたモジュール

  • Ka-Ping Yeeは、ライブPythonコードに関する情報を取得するためのモジュールであるinspect.pyと、ドキュメント文字列をHTMLまたはテキストにインタラクティブに変換するためのモジュールであるpydoc.pyの2つの新しいモジュールを提供しました。 ボーナスとして、現在自動的にインストールされるTools/scripts/pydocは、pydoc.pyを使用して、Pythonモジュール、パッケージ、またはクラス名が指定されたドキュメントを表示します。 たとえば、pydoc xml.domは次のように表示します。

    Python Library Documentation: package xml.dom in xml

NAME
    xml.dom - W3C Document Object Model implementation for Python.

FILE
    /usr/local/lib/python2.1/xml/dom/__init__.pyc

DESCRIPTION
    The Python mapping of the Document Object Model is documented in the
    Python Library Reference in the section on the xml.dom package.

    This package contains the following modules:
      ...

    pydocには、Tkベースのインタラクティブヘルプブラウザも含まれています。 pydocはすぐに中毒性になります。 やってみて！

  • ユニットテスト用の2つの異なるモジュールが標準ライブラリに追加されました。 TimPetersによって提供された doctest モジュールは、docstringに埋め込まれた例を実行し、結果を期待される出力と比較することに基づいたテストフレームワークを提供します。 Steve Purcellによって提供されたPyUnitは、JUnitに触発されたユニットテストフレームワークであり、JUnitはKentBeckのSmalltalkテストフレームワークを適応させたものです。 PyUnitの詳細については、 http://pyunit.sourceforge.net/を参照してください。

  • difflib モジュールには、クラスSequenceMatcherが含まれています。このクラスは、2つのシーケンスを比較し、一方のシーケンスをもう一方のシーケンスに変換するために必要な変更を計算します。 たとえば、このモジュールを使用して、Unix diff プログラムに類似したツールを作成できます。実際、サンプルプログラムTools/scripts/ndiff.pyは、このようなスクリプトの作成方法を示しています。

  • curses.panel は、ncursesとSYSV cursesの一部であるパネルライブラリのラッパーであり、ThomasGellekumによって提供されました。 パネルライブラリは、ウィンドウに奥行きの追加機能を提供します。 ウィンドウは深さの順序で上下に移動でき、パネルライブラリは、パネルが重なっている場所と表示されているセクションを特定します。

  • PyXMLパッケージはPython2.0以降いくつかのリリースを経ており、Python2.1には xml パッケージの更新バージョンが含まれています。 注目すべき変更には、Expat 1.2以降のバージョンのサポート、Pythonでサポートされている任意のエンコーディングでファイルを処理するExpatパーサーの機能、SAX、DOM、およびminidomモジュールのさまざまなバグ修正が含まれます。

  • Pingは、キャッチされなかった例外を処理するための別のフックにも貢献しました。 sys.excepthook（）は呼び出し可能なオブジェクトに設定できます。 try … except ブロックで例外がキャッチされない場合、例外は sys.excepthook（）に渡され、 sys.excepthook（）はそれを実行できます。好きです。 第9回PythonConferenceで、Pingはこのフックのアプリケーションをデモンストレーションしました。スタックフレームを一覧表示するだけでなく、各フレームの関数引数とローカル変数も一覧表示する拡張トレースバックを出力します。

  • asctime()やlocaltime()など、 time モジュールのさまざまな関数には、エポックからの秒単位の時間を含む浮動小数点引数が必要です。 これらの関数の最も一般的な使用法は現在の時刻を操作することであるため、浮動小数点引数はオプションになっています。 値が指定されていない場合は、現在の時刻が使用されます。 たとえば、ログファイルのエントリには通常、現在の時刻を含む文字列が必要です。 Python 2.1では、以前は必要だった長いtime.asctime(time.localtime(time.time()))の代わりに、time.asctime()を使用できます。

    この変更は、ThomasWoutersによって提案および実装されました。

  • ftplib モジュールは、パッシブモードでファイルを取得するようにデフォルト設定されるようになりました。これは、パッシブモードがファイアウォールの背後から機能する可能性が高いためです。 他のDebianパッケージは ftplib を使用してファイルを取得し、ファイアウォールの背後からは機能しないため、このリクエストはDebianバグ追跡システムから送信されました。 Netscapeはデフォルトでパッシブモードに設定されており、不満を言う人はほとんどいないため、これが問題を引き起こす可能性は低いと考えられますが、パッシブモードがアプリケーションやネットワーク設定に適していない場合は、FTPオブジェクトでset_pasv(0)を呼び出してパッシブモードを無効にします。

  • GrantEdwardsによって提供された socket モジュールにrawソケットアクセスのサポートが追加されました。

  • pstats モジュールには、モジュールがスクリプトとして実行されるときに呼び出される、Pythonプログラムのタイミングプロファイルを表示するためのシンプルなインタラクティブ統計ブラウザが含まれるようになりました。 EricSによる寄稿。 レイモンド。

  • 現在の呼び出しスタックから特定のフレームオブジェクトを返すために、新しい実装依存関数sys._getframe([depth])が追加されました。 sys._getframe（）は、呼び出しスタックの最上位にあるフレームを返します。 オプションの整数引数 depth が指定されている場合、関数はスタックの最上位より下の depth 呼び出しであるフレームを返します。 たとえば、sys._getframe(1)は呼び出し元のフレームオブジェクトを返します。

    この関数はCPythonにのみ存在し、Jythonや.NET実装には存在しません。 デバッグに使用し、本番コードに入れたいという誘惑に抵抗してください。


その他の変更と修正

リリースサイクルが短いため、Python2.1で行われた小さな変更は比較的少なかった。 CVS変更ログを検索すると、117個のパッチが適用され、136個のバグが修正されています。 どちらの数値も過小評価される可能性があります。 より注目すべき変更点は次のとおりです。

  • 専用のオブジェクトアロケータがオプションで利用できるようになりました。これは、システムmalloc()よりも高速で、メモリのオーバーヘッドが少ないはずです。 アロケータは、Cのmalloc()関数を使用してメモリの大きなプールを取得し、これらのプールからの小さなメモリ要求を実行します。 configure スクリプトに--with-pymallocオプションを指定することで有効にできます。 実装の詳細については、Objects/obmalloc.cを参照してください。

    C拡張モジュールの作成者は、オブジェクトアロケータを有効にしてコードをテストする必要があります。これは、一部の誤ったコードが破損し、実行時にコアダンプが発生する可能性があるためです。 PythonのCAPIには、以前はCライブラリのmalloc()およびfree()のエイリアスであったメモリ割り当て関数がたくさんあります。つまり、誤って不一致の関数を呼び出した場合でも、エラーは発生しません。目立つようにします。 オブジェクトアロケータが有効になっている場合、これらの関数はmalloc()およびfree()のエイリアスではなくなり、メモリを解放するために間違った関数を呼び出すとコアダンプが発生します。 たとえば、メモリがPyMem_New()を使用して割り当てられた場合、free()ではなくPyMem_Del()を使用してメモリを解放する必要があります。 Pythonに含まれているいくつかのモジュールはこれに反し、修正する必要がありました。 同じ問題を抱えるサードパーティのモジュールが他にもあることは間違いありません。

    オブジェクトアロケータは、VladimirMarangozovによって提供されました。

  • 行指向のファイルI / Oの速度は、速度の不足について人々が不満を言うことが多く、ナイーブなベンチマークとして使用されることが多いため、改善されました。 したがって、ファイルオブジェクトの readline（）メソッドは、はるかに高速になるように書き直されました。 スピードアップの正確な量は、Cライブラリのgetc()の速度に応じてプラットフォームごとに異なりますが、約66％であり、特定のオペレーティングシステムでははるかに高速になる可能性があります。 Tim Petersは、comp.lang.pythonでの議論に動機付けられて、この変更のベンチマークとコーディングの多くを行いました。

    Jeff Eplerによって提供された、ファイルオブジェクト用の新しいモジュールとメソッドも追加されました。 新しいメソッドxreadlines()は、既存のxrange()ビルトインに似ています。 xreadlines()は、反復をサポートするだけの不透明なシーケンスオブジェクトを返します。反復ごとに行を読み取りますが、既存のreadlines()メソッドのようにファイル全体をメモリに読み取ることはありません。 あなたはそれをこのように使うでしょう：

    for line in sys.stdin.xreadlines():
    # ... do something for each line ...
    ...

    ラインI / Oの変更の詳細については、2001年1月1〜15日のpython-devの概要（ https://mail.python.org/pipermail/python-dev/2001-January/ [）を参照してください。 X164X]。

  • 新しいメソッドpopitem()が辞書に追加され、辞書の内容を破壊的に反復できるようになりました。 すべてのキーまたは値を含むリストを作成する必要がないため、これは大きな辞書の場合は高速になります。 D.popitem()は、ランダムな(key, value)ペアを辞書Dから削除し、2タプルとして返します。 これは、Moshe Zadkaによる提案と予備パッチの後、主にTimPetersとGuidovanRossumによって実装されました。

  • モジュールは、インポートされる名前のリストを含む__all__属性を定義することにより、from module import *が使用されるときにインポートされる名前を制御できるようになりました。 よくある不満の1つは、モジュールが sys や string などの他のモジュールをインポートすると、from module import *がそれらをインポートするモジュールの名前空間に追加することです。 これを修正するには、__all__にパブリック名をリストするだけです。

    # List public names
__all__ = ['Database', 'open']

    このパッチのより厳密なバージョンが最初に提案され、Ben Wolfsonによって実装されましたが、python-devでの議論の後、より弱い最終バージョンがチェックインされました。

  • repr（）を、印刷不可能な文字に対して以前に使用されていた8進エスケープを文字列に適用します。 たとえば、改行は'\012'でした。 これはPythonの祖先の痕跡でしたが、今日では8進数はほとんど実用的ではありません。 Ka-Ping Yeeは、8進数ではなく16進数のエスケープを使用し、適切な文字に\n、\t、\rエスケープを使用することを提案し、この新しいフォーマットを実装しました。

  • コンパイル時に検出された構文エラーにより、エラーのファイル名と行番号を含む例外が発生する可能性があります。これは、JeremyHyltonによるコンパイラーの再編成の快適な副作用です。

  • 他のモジュールをインポートするC拡張機能は、PyImport_ImportModule()を使用するように変更されました。これは、インストールされているすべてのインポートフックを使用することを意味します。 これは、Cコードから他のモジュールをインポートする必要があるサードパーティの拡張機能にも推奨されます。

  • Unicode文字データベースのサイズは、FredrikLundhのおかげでさらに340K縮小されました。

  • いくつかの新しいポートが提供されました：MacOS X（Steven Majewskiによる）、Cygwin（Jason Tishlerによる）。 RISCOS（Dietmar Schwertbergerによる）; Unixware 7（BillyGによる）。 アリー）。

また、マイナーなバグ修正、マイナーなメモリリーク、docstringの編集、その他の微調整の通常のリストがありますが、長すぎて項目化する価値がありません。 必要に応じて、詳細についてはCVSログを参照してください。


謝辞

著者は、この記事のさまざまなドラフトについて提案を提供してくれた次の人々に感謝します：Graeme Cross、David Goodger、Jay Graves、Michael Hudson、Marc-AndréLemburg、Fredrik Lundh、Neil Schemenauer、ThomasWouters。



「https://www.finddevguides.com/index.php?title=Python/docs/3.8/whatsnew/2.1&oldid=99310」から取得
Powered by MediaWiki