6. 単純文 (simple statement)¶
単純文とは、単一の論理行内に収められる文です。単一の行内には、複数の単純文をセミコロンで区切って入れることができます。単純文の構文は以下の通りです:
simple_stmt ::=expression_stmt|assert_stmt|assignment_stmt|augmented_assignment_stmt|pass_stmt|del_stmt|print_stmt|return_stmt|yield_stmt|raise_stmt|break_stmt|continue_stmt|import_stmt|future_stmt|global_stmt|exec_stmt
6.1. 式文 (expression statement)¶
式文は、(主に対話的な使い方では) 値を計算して出力するために使ったり、(通常は) プロシジャ (procedure: 有意な結果を返さない関数のことです; Python では、プロシジャは値 None を返します) を呼び出すために使います。その他の使い方でも式文を使うことができますし、有用なこともあります。式文の構文は以下の通りです:
expression_stmt ::= expression_list
式文は式のリスト (単一の式のこともあります) を値評価します。
対話モードでは、値が None でない場合、値を組み込み関数 repr() で文字列に変換して、その結果のみからなる一行を標準出力に書き出します ( print 文 節参照 ) 。 (None になる式文の値は書き出されないので、プロシジャ呼び出しを行っても出力は得られません。 )
6.2. 代入文 (assignment statement)¶
代入文は、名前を値に (再) 束縛したり、変更可能なオブジェクトの属性や要素を変更したりするために使われます:
assignment_stmt ::= (target_list"=")+ (expression_list|yield_expression) target_list ::=target(","target)* [","] target ::=identifier| "("target_list")" | "[" [target_list] "]" |attributeref|subscription|slicing
(末尾の三つのシンボルの構文については プライマリ 節を参照してください。)
代入文は式のリスト (これは単一の式でも、カンマで区切られた式リストでもよく、後者はタプルになることを思い出してください) を評価し、得られた単一の結果オブジェクトをターゲット (target) のリストに対して左から右へと代入してゆきます。
代入はターゲット (リスト) の形式に従って再帰的に行われます。ターゲットが変更可能なオブジェクト (属性参照、添字表記、またはスライス) の一部である場合、この変更可能なオブジェクトは最終的に代入を実行して、その代入が有効な操作であるか判断しなければなりません。代入が不可能な場合には例外を発行することもできます。型ごとにみられる規則や、送出される例外は、そのオブジェクト型定義で与えられています (標準型の階層 節を参照してください).
ターゲットリストへのオブジェクトの代入は、以下のようにして再帰的に定義されています。
ターゲットリストが単一のターゲットからなる場合: オブジェクトはそのターゲットに代入されます。
ターゲットリストが、カンマで区切られた複数のターゲットからなるリストの場合: オブジェクトはターゲットリスト中のターゲット数と同じ数の要素からなるイテレート可能オブジェクトでなければならず、その各要素は左から右へと対応するターゲットに代入されます。
単一のターゲットへの単一のオブジェクトの代入は、以下のようにして再帰的に定義されています。
ターゲットが識別子 (名前) の場合:
名前が現在のコードブロック内の
global文に書かれていない場合 : 名前は現在のローカル名前空間内のオブジェクトに束縛されます。それ以外の場合 : 名前は現在のグローバル名前空間内のオブジェクトに束縛されます。
名前がすでに束縛済みの場合、再束縛 (rebind) がおこなわれます。再束縛によって、以前その名前に束縛されていたオブジェクトの参照カウント (reference count) がゼロになった場合、オブジェクトは解放 (deallocate) され、デストラクタ (destructor) が (存在すれば) 呼び出されます。
ターゲットが丸括弧や角括弧で囲われたターゲットリストの場合: オブジェクトはターゲットリスト中のターゲット数と同じ数の要素からなるイテレート可能オブジェクトでなければならず、その各要素は左から右へと対応するターゲットに代入されます。
ターゲットが属性参照の場合: 参照されている一次語の式が値評価されます。値は代入可能な属性を伴うオブジェクトでなければなりません; そうでなければ、
TypeErrorが送出されます。次に、このオブジェクトに対して、被代入オブジェクトを指定した属性に代入してよいか問い合わせます; 代入を実行できない場合、例外 (通常はAttributeErrorですが、必然ではありません) を送出します。注意: オブジェクトがクラスインスタンスで、代入演算子の両辺に属性参照があるとき、右辺式の
a.xはインスタンスの属性と (インスタンスの属性が存在しなければ) クラス属性のどちらにもアクセスする可能性があります。左辺のターゲットa.xは常にインスタンスの属性として割り当てられ、必要ならば生成されます。このとおり、現れる二つのa.xは同じ値を参照するとは限りません: 右辺式はクラス属性を参照し、左辺は新しいインスタンス属性を代入のターゲットとして生成するようなとき:class Cls: x = 3 # class variable inst = Cls() inst.x = inst.x + 1 # writes inst.x as 4 leaving Cls.x as 3
このことは、
property()で作成されたプロパティのようなデスクリプタ属性に対しては、必ずしもあてはまるとは限りません。ターゲットが添字表記の場合 : 参照されている一次語の式が値評価されます。まず、値は変更可能な ( リストのような ) シーケンスオブジェクトか、 ( 辞書のような ) マップオブジェクトでなければなりません。次に、添字表記の表す式が値評価されます。
一次語が変更可能な ( リストのような ) シーケンスオブジェクトの場合、まず添字は整数でなければなりません。添字が負数の場合、シーケンスの長さが加算されます。添字は最終的に、シーケンスの長さよりも小さな非負の整数でなくてはなりません。次に、添字をインデクスに持つ要素に非代入オブジェクトを代入してよいか、シーケンスに問い合わせます。範囲を超えたインデクスに対しては
IndexErrorが送出されます ( 添字指定されたシーケンスに代入を行っても、リスト要素の新たな追加はできません ) 。一次語が (辞書のような) マップオブジェクトの場合、まず添字はマップのキー型と互換性のある型でなくてはなりません。次に、添字を被代入オブジェクトに関連付けるようなキー/データの対を生成するようマップオブジェクトに問い合わせます。この操作では、既存のキー/値の対を同じキーと別の値で置き換えてもよく、(同じ値を持つキーが存在しない場合) 新たなキー/値の対を挿入してもかまいません。
ターゲットがスライスの場合 : 参照されている一次語の式が値評価されます。まず、値は変更可能な ( リストのような ) シーケンスオブジェクトでなければなりません。被代入オブジェクトは同じ型を持ったシーケンスオブジェクトでなければなりません。次に、スライスの下境界と上境界を示す式があれば評価されます ; デフォルト値はそれぞれゼロとシーケンスの長さです。上下境界は整数にならなければなりません。いずれかの境界が負数になった場合、シーケンスの長さが加算されます。最終的に、境界はゼロからシーケンスの長さまでの内包になるようにクリップされます。最後に、スライスを被代入オブジェクトで置き換えてよいかシーケンスオブジェクトに問い合わせます。オブジェクトで許されている限り、スライスの長さは被代入シーケンスの長さと異なっていてよく、この場合にはターゲットシーケンスの長さが変更されます。
現在の実装では、ターゲットの構文は式の構文と同じであるとみなされており、無効な構文はコード生成フェーズ中に詳細なエラーメッセージを伴って拒否されます。
警告: 代入の定義では、左辺値と右辺値がオーバラップするような代入 (例えば、 a, b = b, a を行うと、二つの変数を入れ替えます) を定義しても '安全 (safe)' に代入できますが、代入対象となる変数群 の間で オーバラップがある場合は安全ではありません!例えば、以下のプログラムは [0, 2] を出力してしまいます:
x = [0, 1]
i = 0
i, x[i] = 1, 2
print x
6.2.1. 累算代入文 (augmented assignment statement)¶
累算代入文は、二項演算と代入文を組み合わせて一つの文にしたものです:
augmented_assignment_stmt ::=augtargetaugop(expression_list|yield_expression) augtarget ::=identifier|attributeref|subscription|slicingaugop ::= "+=" | "-=" | "*=" | "/=" | "//=" | "%=" | "**=" | ">>=" | "<<=" | "&=" | "^=" | "|="
(末尾の三つのシンボルの構文については プライマリ 節を参照してください。)
累算代入文は、ターゲット (通常の代入文と違って、アンパックは起こりません) と式リストを評価し、それら二つの被演算子間で特定の累算代入型の二項演算を行い、結果をもとのターゲットに代入します。ターゲットは一度しか評価されません。
x += 1 のような累算代入式は、 x = x + 1 のように書き換えてほぼ同様の動作にできますが、厳密に等価にはなりません。累算代入の方では、 x は一度しか評価されません。また、実際の処理として、可能ならば インプレース (in-place) 演算が実行されます。これは、代入時に新たなオブジェクトを生成してターゲットに代入するのではなく、以前のオブジェクトの内容を変更するということです。
累算代入文で行われる代入は、タプルへの代入や、一文中に複数のターゲットが存在する場合を除き、通常の代入と同じように扱われます。同様に、累算代入で行われる二項演算は、場合によって インプレース演算 が行われることを除き、通常の二項演算と同じです。
属性参照のターゲットの場合、 クラスとインスタンスの属性についての注意 と同様に通常の代入が適用されます。
6.3. assert 文¶
assert 文は、プログラム内にデバッグ用アサーション (debugging assertion) を仕掛けるための便利な方法です:
assert_stmt ::= "assert"expression[","expression]
単純な形式 assert expression は
if __debug__:
if not expression: raise AssertionError
と等価です。拡張形式 assert expression1, expression2 は、これと等価です
if __debug__:
if not expression1: raise AssertionError(expression2)
上記の等価関係は、 __debug__ と AssertionError が、同名の組み込み変数を参照しているという前提の上に成り立っています。現在の実装では、組み込み変数 __debug__ は通常の状況では True であり、最適化がリクエストされた場合(コマンドラインオプション -O)は False です。現状のコード生成器は、コンパイル時に最適化が要求されていると assert 文に対するコードを全く出力しません。実行に失敗した式のソースコードをエラーメッセージ内に入れる必要はありません; コードはスタックトレース内で表示されます。
__debug__ への代入は不正な操作です。組み込み変数の値は、インタプリタが開始するときに決定されます。
6.4. pass 文¶
pass_stmt ::= "pass"
pass はヌル操作 (null operation) です --- pass が実行されても、何も起きません。 pass は、構文法的には文が必要だが、コードとしては何も実行したくない場合のプレースホルダとして有用です。例えば:
def f(arg): pass # a function that does nothing (yet)
class C: pass # a class with no methods (yet)
6.5. del 文¶
del_stmt ::= "del" target_list
オブジェクトの削除 (deletion) は、代入の定義と非常に似た方法で再帰的に定義されています。ここでは完全な詳細は記述せず、いくつかのヒントを述べるにとどめます。
ターゲットリストに対する削除は、各々のターゲットを左から右へと順に再帰的に削除します。
名前に対して削除を行うと、ローカルまたはグローバル名前空間でのその名前の束縛を解除します。どちらの名前空間かは、名前が同じコードブロック内の global 文で宣言されているかどうかによります。名前が未束縛 (unbound) であるばあい、 NameError 例外が送出されます。
ネストしたブロック中で自由変数になっているローカル名前空間上の名前に対する削除は不正な操作になります
属性参照、添字表記、およびスライスの削除操作は、対象となる一次語オブジェクトに渡されます; スライスの削除は一般的には適切な型の空のスライスを代入するのと等価です (が、この仕様自体もスライスされるオブジェクトで決定されています)。
6.6. print 文¶
print_stmt ::= "print" ([expression(","expression)* [","]] | ">>"expression[(","expression)+ [","]])
print は、式を逐次的に評価し、得られたオブジェクトを標準出力に書き出します。オブジェクトが文字列でなければ、まず文字列変換規則を使って文字列に変換され、次いで ( 得られた文字列か、オリジナルの文字列が ) 書き出されます。出力系の現在の書き出し位置が行頭にあると考えられる場合を除き、各オブジェクトの出力前にスペースが一つ出力されます。行頭にある場合とは、 (1) 標準出力にまだ何も書き出されていない場合、 (2) 標準出力に最後に書き出された文字が ' ' を除く空白である、または (3) 標準出力に対する最後の書き出し操作が print 文によるものではない場合、です。 ( こうした理由から、場合によっては空文字を標準出力に書き出すと便利なことがあります。 )
注釈
組み込みのファイルオブジェクトでない、ファイルオブジェクトに似た動作をするオブジェクトでは、組み込みのファイルオブジェクトが持つ上記の性質を適切にエミュレートしていないことがあるため、当てにしないほうがよいでしょう。
print 文がカンマで終了していない限り、末尾には文字 '\n' が書き出されます。この仕様は、文に予約語 print がある場合のみの動作です。
標準出力は、組み込みモジュール sys 内で stdout という名前のファイルオブジェクトとして定義されています。該当するオブジェクトが存在しないか、オブジェクトに write() メソッドがない場合、 RuntimeError 例外が送出されます。 .
print には、上で説明した構文の第二形式で定義されている拡張形式があります。この形式は、 " 山形 print 表記 (print chevron)" と呼ばれます。この形式では、 >> の直後にくる最初の式の値評価結果は " ファイル類似 (file-like)" なオブジェクト、とりわけ上で述べたように write() メソッドを持つオブジェクトでなければなりません。この拡張形式では、ファイルオブジェクトを指定する式よりも後ろの式が、指定されたファイルオブジェクトに出力されます。最初の式の値評価結果が None になった場合、 sys.stdout が出力ファイルとして使われます。
6.7. return 文¶
return_stmt ::= "return" [expression_list]
return は、関数定義内で構文法的にネストして現れますが、ネストしたクラス定義内には現れません。
式リストがある場合、リストが値評価されます。それ以外の場合は None で置き換えられます。
return を使うと、式リスト (または None) を戻り値として、現在の関数呼び出しから抜け出します。
return によって、 finally 節をともなう try 文の外に処理が引き渡されると、実際に関数から抜ける前に finally 節が実行されます。
ジェネレータ関数の場合には、 return 文の中に expression_list を入れることはできません。ジェネレータ関数の処理コンテキストでは、単体の return はジェネレータ処理を終了し StopIteration を送出させることを示します。
6.8. yield 文¶
yield_stmt ::= yield_expression
yield 文は、ジェネレータ関数 (generator function) を定義するときだけ使われ、かつジェネレータ関数の本体の中でだけ用いられます。関数定義中で yield 文を使うだけで、関数定義は通常の関数でなくジェネレータ関数になります。
ジェネレータ関数が呼び出されると、ジェネレータイテレータ (generator iterator) 、一般的にはジェネレータ (generator) を返します。ジェネレータ関数の本体は、ジェネレータの next() が例外を発行するまで繰り返し呼び出して実行します。
yield 文が実行されると、現在のジェネレータの状態は凍結 (freeze) され、 expression_list の値が next() の呼び出し側に返されます。ここでの "凍結" は、ローカルな変数への束縛、命令ポインタ (instruction pointer) 、および内部実行スタック (internal evaluation stack) を含む、全てのローカルな状態が保存されることを意味します : すなわち、必要な情報を保存しておき、次に next() が呼び出された際に、関数が yield 文をあたかももう一つの外部呼出しであるかのように処理できるようにします。
Python バージョン 2.5 では、 yield 文が try ... finally 構造における try 節で許されるようになりました。ジェネレータが終了( finalized )される(参照カウントがゼロになるか、ガベージコレクションされる ) までに再開されなければ、ジェネレータ - イテレータの close() メソッドが呼ばれ、留保されている finally 節が実行できるようになります。
yield の意味の完全な説明は、 Yield 式 節を参照してください。
注釈
Python 2.2 では、 generators 機能が有効になっている場合にのみ yield 文を使えました。この機能を有効にするための __future__ import 文は次のとおりでした。
from __future__ import generators
6.9. raise 文¶
raise_stmt ::= "raise" [expression[","expression[","expression]]]
式を伴わない場合、 raise は現在のスコープで最終的に有効になっている例外を再送出します。そのような例外が現在のスコープでアクティブでない場合、 TypeError 例外が送出されて、これがエラーであることを示します (IDLE で実行した場合は、代わりに exceptionQueue.Empty 例外を送出します ) 。
それ以外の場合、 raise は式を値評価して、三つのオブジェクトを取得します。このとき、 None を省略された式の値として使います。最初の二つのオブジェクトは、例外の * 型 (type)* と例外の * 値 (value)* を決定するために用いられます。
最初のオブジェクトがインスタンスである場合、例外の型はインスタンスのクラスになり、インスタンス自体が例外の値になります。このとき第二のオブジェクトは None でなければなりません。
最初のオブジェクトがクラスの場合、例外の型になります。第二のオブジェクトは、例外の値を決めるために使われます : 第二のオブジェクトがインスタンスならば、そのインスタンスが例外の値になります。第二のオブジェクトがタプルの場合、クラスのコンストラクタに対する引数リストとして使われます ; None なら、空の引数リストとして扱われ、それ以外の型ならコンストラクタに対する単一の引数として扱われます。このようにしてコンストラクタを呼び出して生成したインスタンスが例外の値になります。
第三のオブジェクトが存在し、かつ None でなければ、オブジェクトはトレースバックオブジェクトでなければなりません ( 標準型の階層 節参照 ) 。また、例外が発生した場所は現在の処理位置に置き換えられます。第三のオブジェクトが存在し、オブジェクトがトレースバックオブジェクトでも None でもなければ、 TypeError 例外が送出されます。 raise の三連式型は、 except 節から透過的に例外を再送出するのに便利ですが、再送出すべき例外が現在のスコープで発生した最も新しいアクティブな例外である場合には、式なしの raise を使うよう推奨します。
6.10. break 文¶
break_stmt ::= "break"
break 文は、構文としては for ループや while ループの内側でのみ出現することができますが、ループ内の関数定義やクラス定義の内側には出現できません。
break 文は、文を囲う最も内側のループを終了させ、ループにオプションの else 節がある場合にはそれをスキップします。
for ループを break によって終了すると、ループ制御ターゲットはその時の値を保持します。
break が finally 節を伴う try 文の外側に処理を渡す際には、ループを実際に抜ける前にその finally 節が実行されます。
6.11. continue 文¶
continue_stmt ::= "continue"
continue 文は for ループや while ループ内のネストで構文法的にのみ現れますが、ループ内の関数定義やクラス定義、 finally 句の中には現れません。 continue 文は、文を囲う最も内側のループの次の周期に処理を継続します。
continue が finally 句を持った try 文を抜けるとき、その finally 句が次のループサイクルを始める前に実行されます。
6.12. import 文¶
import_stmt ::= "import"module["as"name] ( ","module["as"name] )* | "from"relative_module"import"identifier["as"name] ( ","identifier["as"name] )* | "from"relative_module"import" "("identifier["as"name] ( ","identifier["as"name] )* [","] ")" | "from"module"import" "*" module ::= (identifier".")*identifierrelative_module ::= "."*module| "."+ name ::=identifier
import 文は、 (1) モジュールを探し、必要なら初期化 (initialize) する ; (import 文のあるスコープにおける ) ローカルな名前空間で名前を定義する、の二つの段階を踏んで初期化されます。 import 文には、 from を使うか使わないかの 2 種類の形式があります。第一形式 (from のない形式 ) は、上記の段階をリスト中にある各識別子に対して繰り返し実行していきます。 from のある形式では、 (1) を一度だけ行い、次いで (2) を繰り返し実行します。
ステップ (1) がどのように行われるのかを理解するには、まず、 Python が階層的なモジュール名をどう扱うのかを理解する必要があります。モジュールを組織化し名前に階層を持たせるために、 Python はパッケージという概念を持っています。モジュールが他のモジュールやパッケージを含むことができないのに対して、パッケージは他のパッケージやモジュールを含むことができます。ファイルシステムの視点から見ると、パッケージはディレクトリでモジュールはファイルです。
モジュール名 ( 特に記述していない場合は、 " モジュール " とはパッケージとモジュール両方を指しています ) が判ったとき、モジュールかパッケージの検索が始まります。最初にチェックされる場所は、それまでにインポートされたすべてのモジュールのキャッシュである sys.modules です。もしモジュールがそこで見つかれば、それが import のステップ (2) で利用されます。
キャッシュにモジュールが見つからなかった場合、次は sys.meta_path が検索されます。 (sys.meta_path の仕様は PEP 302 に見つけることができます。) これは finder オブジェクトのリストで、そのモジュールを読み込む方法を知っているかどうかをその find_module() メソッドをモジュール名を引数として呼び出すことで、順番に問い合せていきます。モジュールがパッケージに含まれていた (モジュール名の中にドットが含まれていた) 場合、 find_module() の第 2 引数に親パッケージの __path__ 属性が渡されます。 (モジュール名の最後のドットより前のすべてがインポートされます) finder はモジュールを見つけたとき、 (後で解説する) loader か None を返します。
sys.meta_path に含まれるすべての finder が module を見つけられない場合、幾つかの暗黙的に定義されている finder に問い合わせられます。どんな暗黙の meta path finder が定義されているかは Python の実装によって様々です。すべての実装が定義しなければならない 1 つの finder は、 sys.path_hooks を扱います。
この暗黙の finder は要求されたモジュールを、 2 箇所のどちらかで定義されている "paths" から探します。 ("paths" がファイルシステムパスである必要はありません ) インポートしようとしているモジュールがパッケージに含まれている場合、親パッケージの __path__ が find_module() の第 2 引数として渡され、それが paths として扱われます。モジュールがパッケージに含まれていない場合、 sys.path が paths として扱われます。
paths が決定されたら、それを巡回してその path を扱える finder を探します。 sys.path_importer_cache 辞書は path に対する finder をキャッシュしており、 finder を探すときにチェックされます。 path がキャッシュに登録されていない場合は、 sys.path_hooks の各オブジェクトを 1 つの引数 path で呼び出します。各オブジェクトは finder を返すか、 ImportError を発生させます。 finder が返された場合、それを sys.path_importer_cache にキャッシュして、その path に対してその finder を使います。 finder が見つからず、 path が存在している場合、 None が sys.path_importer_cache に格納されて、暗黙の、単一のファイルとしてモジュールが格納されているとしてあつかうファイルベースの finder をその path に対して利用することを示します。その path が存在しなかった場合、常に None を返す finder がその path に対するキャッシュとして格納されます。
全ての finder がそのモジュールを見つけられないときは、 ImportError が発生します。そうでなければ、どれかの finder が loader を返し、その load_module() メソッドがモジュール名を引数に呼び出されてロードを行ないます。 ( ローダーのオリジナルの定義については PEP 302 を参照してください。 ) loader はロードするモジュールに対して幾つかの責任があります。まず、そのモジュールがすでに sys.modules にあれば、 ( ローダーが import 機構の外から呼ばれた場合に有り得ます ) そのモジュールを初期化に使い、新しいモジュールを使いません。 sys.modules にそのモジュールがなければ、初期化を始める前に sys.modules に追加します。 sys.modules に追加したあと、モジュールのロード中にエラーが発生した場合は、その辞書から削除します。モジュールが既に sys.modules にあった場合は、エラーが発生してもその辞書に残しておきます。
ローダーは幾つかの属性をモジュールに設定しなければなりません。モジュール名を __name__ に設定します。ファイルの "path" を __file__ に設定しますが、ビルトインモジュール (sys.builtin_module_names にリストされている ) の場合にはその属性を設定しません。インポートしているのがパッケージだった場合は、そのパッケージが含むモジュールやパッケージを探す場所の path のリストを __path_ に設定します。 __package__ はオプションですが、そのモジュールやパッケージを含むパッケージ名 ( パッケージに含まれていないモジュールには空文字列 ) を設定するべきです。 __loader__ もオプションですが、そのモジュールをロードした loader オブジェクトを設定するべきです。
ロード中にエラーが発生した場合、他の例外がすでに伝播していないのであれば、 loader は ImportError を発生させます。それ以外の場合は、 loader はロードして初期化したモジュールを返します。
段階 (1) が例外を送出することなく完了したなら、段階 (2) を開始します。
import 文の第一形式は、ローカルな名前空間に置かれたモジュール名をモジュールオブジェクトに束縛し、 import すべき次の識別子があればその処理に移ります。モジュール名の後ろに as がある場合、 as の後ろの名前はモジュールのローカルな名前として使われます。
from 形式は、モジュール名の束縛を行いません : from 形式では、段階 (1) で見つかったモジュール内から、識別子リストの各名前を順に検索し、見つかったオブジェクトを識別子の名前でローカルな名前空間において束縛します。 import の第一形式と同じように、 "as localname" で別名を与えることができます。指定された名前が見つからない場合、 ImportError が送出されます。識別子のリストを星印 ('*') で置き換えると、モジュールで公開されている名前 (public name) 全てを import 文のある場所のローカルな名前空間に束縛します。
モジュールで * 公開されている名前 (public names)* は、モジュールの名前空間内にある __all__ という名前の変数を調べて決定します ; __all__ が定義されている場合、 __all__ はモジュールで定義されていたり、 import されているような名前の文字列からなるシーケンスでなければなりません。 __all__ 内にある名前は、全て公開された名前であり、実在するものとみなされます。 __all__ が定義されていない場合、モジュールの名前空間に見つかった名前で、アンダースコア文字 ('_') で始まっていない全ての名前が公開された名前になります。 __all__ には、公開されている API 全てを入れなければなりません。 __all__ には、 ( モジュール内で import されて使われているライブラリモジュールのように ) API を構成しない要素を意に反して公開してしまうのを避けるという意図があります。
* を使った from 形式は、モジュールのスコープ内だけに作用します。関数内でワイルドカードの import 文 --- import * --- を使い、関数が自由変数を伴うネストされたブロックであったり、ブロックを含んでいる場合、コンパイラは SyntaxError を送出します。
インポートするモジュールを指定するとき、そのモジュールの絶対名 (absolute name) を指定する必要はありません。モジュールやパッケージが他のパッケージに含まれている場合、共通のトップパッケージからそのパッケージ名を記述することなく相対インポートすることができます。 from の後に指定されるモジュールやパッケージの先頭に複数個のドットを付けることで、正確な名前を指定することなしに現在のパッケージ階層からいくつ上の階層へ行くかを指定することができます。先頭のドットが 1 つの場合、 import をおこなっているモジュールが存在する現在のパッケージを示します。 3 つのドットは 2 つ上のレベルを示します。なので、 pkg パッケージの中のモジュールで from . import mod を実行すると、 pkg.mod をインポートすることになります。 pkg.subpkg1 の中から from ..subpkg2 import mod を実行すると、 pkg.subpkg2.mod をインポートします。相対インポートの仕様は PEP 328 に含まれています。
どのモジュールがロードされるべきかを動的に決めたいアプリケーションのために、組み込み関数 importlib.import_module() が提供されています。
6.12.1. future 文 (future statement)¶
future 文 は、将来の特定の Python のリリースで利用可能になるような構文や意味付けを使って、特定のモジュールをコンパイルさせるための、コンパイラに対する指示句 (directive) です。 future 文は、言語仕様に非互換性がもたらされるような、将来の Python のバージョンに容易に移行できるよう意図されています。 future 文によって、新たな機能が標準化されたリリースが出される前に、その機能をモジュール単位で使えるようにします。
future_statement ::= "from" "__future__" "import" feature ["as" name]
("," feature ["as" name])*
| "from" "__future__" "import" "(" feature ["as" name]
("," feature ["as" name])* [","] ")"
feature ::= identifier
name ::= identifier
future 文は、モジュールの先頭周辺に書かなければなりません。 future 文の前に書いてよい内容は以下です :
モジュールのドキュメンテーション文字列 ( あれば )
コメント ,
空行 ,
その他の future 文。
Python 2.6 が認識する機能は、 unicode_literals, print_function, absolute_import, division, generators, nested_scopes, with_statement です。 generators, with_statement, nested_scopes は Python 2.6 以上では常に有効なので冗長です。
future 文は、コンパイル時に特別なやり方で認識され、扱われます: 言語の中核をなす構文構成 (construct) に対する意味付けが変更されている場合、変更部分はしばしば異なるコードを生成することで実現されています。新たな機能によって、(新たな予約語のような) 互換性のない新たな構文が取り入れられることさえあります。この場合、コンパイラはモジュールを別のやりかたで解析する必要があるかもしれません。こうしたコード生成に関する決定は、実行時まで先延ばしすることはできません。
これまでの全てのリリースにおいて、コンパイラはどの機能が定義済みかを知っており、 future 文に未知の機能が含まれている場合にはコンパイル時エラーを送出します。
future 文の実行時における直接的な意味付けは、 import 文と同じです。標準モジュール __future__ があり、これについては後で述べます。 __future__ は、 future 文が実行される際に通常の方法で import されます。
future 文の実行時における特別な意味付けは、 future 文で有効化される特定の機能によって変わります。
以下の文には、何ら特殊な意味はないので注意してください:
import __future__ [as name]
これは future 文ではありません; この文は通常の import 文であり、その他の特殊な意味付けや構文的な制限はありません。
future 文の入ったモジュール M 内で使われている exec 文、組み込み関数 compile() や execfile() によってコンパイルされるコードは、デフォルトの設定では、 future 文に関係する新たな構文や意味付けを使うようになっています。 Python 2.2 からは、この仕様を compile() のオプション引数で制御できるようになりました --- 詳細はこの関数に関するドキュメントを参照してください。
対話的インタプリタのプロンプトでタイプ入力した future 文は、その後のインタプリタセッション中で有効になります。インタプリタを -i オプションで起動して実行すべきスクリプト名を渡し、スクリプト中に future 文を入れておくと、新たな機能はスクリプトが実行された後に開始する対話セッションで有効になります。
参考
- PEP 236 - Back to the __future__
__future__ 機構の原案
6.13. global 文¶
global_stmt ::= "global"identifier(","identifier)*
global 文は、現在のコードブロック全体で維持される宣言文です。 global 文は、列挙した識別子をグローバル変数として解釈するよう指定することを意味します。 global を使わずにグローバル変数に代入を行うことは不可能ですが、自由変数を使えばその変数をグローバルであると宣言せずにグローバル変数を参照することができます。
global 文で列挙する名前は、同じコードブロック中で、プログラムテキスト上 global 文より前に使ってはなりません。
global 文で列挙する名前は、 for ループのループ制御ターゲットや、 class 定義、関数定義、 import 文内で仮引数として使ってはなりません。
現在の実装では、後ろ二つの制限については強制していませんが、プログラムでこの緩和された仕様を乱用すべきではありません。将来の実装では、この制限を強制したり、暗黙のうちにプログラムの意味付けを変更したりする可能性があります。
プログラマのための注意書き: global はパーサーに対する指示句 (directive) です。この指示句は、 global 文と同時に読み込まれたコードに対してのみ適用されます。特に、 exec 文内に入っている global 文は、 exec 文を * 含んでいる * コードブロック内に効果を及ぼすことはなく、 exec 文内に含まれているコードは、 exec 文を含むコード内での global 文に影響を受けません。同様のことが、関数 eval() 、 execfile() 、および compile() にも当てはまります。
6.14. exec 文¶
exec_stmt ::= "exec"or_expr["in"expression[","expression]]
この文は、 Python コードの動的な実行をサポートします。最初の式の値評価結果 Unicode 文字列, Latin-1 エンコード文字列, 開かれたファイルオブジェクト, コードオブジェクト, タプルのいずれかでなければなりません。文字列の場合、一連の Python 実行文として解析し、 (構文エラーが生じない限り) 実行します。 1 開かれたファイルであれば、ファイルを EOF まで読んで解析し、実行します。コードオブジェクトなら、単にこれを実行します。タプルの翻訳については後述します。全ての場合で、実行されたコードはファイル入力として有効であることが期待されます (セクション ファイル入力 を参照) 。 return と yield 文は、 exec 文に渡されたコードの文脈中においても関数定義の外では使われない点に注意してください。
いずれの場合でも、オプションの部分が省略されると、コードは現在のスコープ内で実行されます。 in の後ろに一つだけ式を指定する場合、その式は辞書でなくてはならず、グローバル変数とローカル変数の両方に使われます。これらはそれぞれグローバル変数とローカル変数として使われます。 locals を指定する場合は何らかのマップ型オブジェクトにせねばなりません。モジュールレベルでは、グローバルとローカルは同じ辞書です。 globals と locals として別のオブジェクトを取った場合、コードはクラス定義に埋め込まれたかのように実行されます。
最初の式は長さ 2 か 3 のタプルにできます。このケースの場合は、残りの省略可能部分は省略しなければなりません。 exec(expr, globals) 形式は exec expr in globals と等価で、 exec(expr, globals, locals) 形式は exec expr in globals, locals と等価です。 exec のタプル形式は、 exec が文ではなく関数になっている Python 3 との互換性を提供します。
バージョン 2.4 で変更: 以前は locals は辞書でなければなりませんでした .
exec の副作用として実行されるコードで設定された変数名に対応する名前の他に、追加のキーを辞書に追加することがあります。例えば、現在の実装では、組み込みモジュール __builtin__ の辞書に対する参照を、 __builtins__ (!) というキーで追加することがあります。
プログラマのためのヒント: 式の動的な評価は、組み込み関数 eval() でサポートされています。組み込み関数 globals() および locals() は、それぞれ現在のグローバル辞書とローカル辞書を返すので、 exec に渡して使うと便利です。
注記
- 1
なお、パーサは Unix スタイルの行末の記法しか受け付けません。コードをファイルから読んでいるなら、必ず、 universal newlines モードで Windows や Mac スタイルの改行を変換してください。
