4. 実行モデル
*************


4.1. プログラムの構造
=====================

Python プログラムはコードブロックから構成されます。 ブロック (*block*)
は、一つのまとまりとして実行される Python プログラムテキストの断片です
。 モジュール、関数本体、そしてクラス定義はブロックであり、対話的に入
力された個々のコマンドもブロックです。 スクリプトファイル (インタープ
リタに標準入力として与えられたり、インタープリタにコマンドライン引数と
して与えられたファイル) もコードブロックです。 スクリプトコマンド (イ
ンタープリタのコマンドライン上で "-c" オプションで指定されたコマンド)
もコードブロックです。 引数 "-m" を使用して、コマンドラインからトップ
レベルスクリプト(すなわちモジュール "__main__" )として実行されるモジュ
ールもまたコードブロックです。組み込み関数 "eval()" や "exec()" に渡さ
れた文字列引数もコードブロックです。

コードブロックは、実行フレーム (*execution frame*) 上で実行されます。
実行フレームには、 (デバッグに使われる) 管理情報が収められています。ま
た、現在のコードブロックの実行が完了した際に、どのようにプログラムの実
行を継続するかを決定しています。


4.2. 名前づけと束縛 (naming and binding)
========================================


4.2.1. 名前の束縛
-----------------

*名前 (name)* は、オブジェクトを参照します。名前を導入するには、名前へ
の束縛 (name binding) 操作を行います。

以下の構文が名前を束縛します:

* formal parameters to functions,

* クラス定義,

* 関数定義,

* 代入式,

* targets that are identifiers if occurring in an assignment:

  * "for" loop header,

  * after "as" in a "with" statement, "except" clause, "except*"
    clause, or in the as-pattern in structural pattern matching,

  * in a capture pattern in structural pattern matching

* "import" 文.

* "type" statements.

* type parameter lists.

The "import" statement of the form "from ... import *" binds all names
defined in the imported module, except those beginning with an
underscore. This form may only be used at the module level.

"del" 文で指定される対象は、("del" の意味付けは、実際は名前の解放
(unbind) ですが) 文の目的上、束縛済みのものとみなされます。

代入文や import 文はいずれも、クラスや関数定義、モジュールレベル (トッ
プレベルのコードブロック) 内で起こります。

If a name is bound in a block, it is a local variable of that block,
unless declared as "nonlocal" or "global".  If a name is bound at the
module level, it is a global variable.  (The variables of the module
code block are local and global.)  If a variable is used in a code
block but not defined there, it is a *free variable*.

プログラムテキスト中に名前が出現するたびに、その名前が使われている最も
内側の関数ブロック中で作成された *束縛 (binding)* を使って名前の参照が
行われます。


4.2.2. 名前解決
---------------

スコープ (*scope*) は、ブロック内の名前の可視性を決めます。 ローカル変
数があるブロック内で定義されている場合、変数のスコープはそのブロックを
含みます。 関数ブロック内で名前の定義を行った場合、その中のブロックが
名前に別の束縛を行わない限り、定義ブロック内の全てのブロックを含むよう
にスコープが拡張されます。

ある名前がコードブロック内で使われると、その名前を最も近傍から囲うよう
なスコープ (最内スコープ: nearest enclosing scope) を使って束縛の解決
を行います。こうしたスコープからなる、あるコードブロック内で参照できる
スコープ全ての集合は、ブロックの環境(*environment*)と呼ばれます。

名前が全く見付からなかったときは、 "NameError" 例外が送出されます。 現
在のスコープが関数のもので、名前が使われる場所でローカル変数がまだ値に
束縛されていない場合、 "UnboundLocalError" 例外が送出されます。
"UnboundLocalError" は "NameError" の子クラスです。

ある名前がコードブロック内のどこかで束縛操作されていたら、そのブロック
内で使われるその名前はすべて、現在のブロックへの参照として扱われます。
このため、ある名前がそのブロック内で束縛される前に使われるとエラーにつ
ながります。この規則は敏感です。Python には宣言がなく、コードブロック
のどこでも名前束縛操作ができます。あるコードブロックにおけるローカル変
数は、ブロックのテキスト全体から名前束縛操作を走査することで決定されま
す。例は UnboundLocalError についての FAQ 項目 を参照してください。

If the "global" statement occurs within a block, all uses of the names
specified in the statement refer to the bindings of those names in the
top-level namespace.  Names are resolved in the top-level namespace by
searching the global namespace, i.e. the namespace of the module
containing the code block, and the builtins namespace, the namespace
of the module "builtins".  The global namespace is searched first.  If
the names are not found there, the builtins namespace is searched
next. If the names are also not found in the builtins namespace, new
variables are created in the global namespace. The global statement
must precede all uses of the listed names.

"global" 文は、同じブロックの束縛操作と同じスコープを持ちます。ある自
由変数の最内スコープに global 文がある場合、その自由変数はグローバル変
数とみなされます。

The "nonlocal" statement causes corresponding names to refer to
previously bound variables in the nearest enclosing function scope.
"SyntaxError" is raised at compile time if the given name does not
exist in any enclosing function scope. Type parameters cannot be
rebound with the "nonlocal" statement.

あるモジュールの名前空間は、そのモジュールが最初に import された時に自
動的に作成されます。スクリプトの主モジュール (main module) は常に
"__main__" と呼ばれます。

Class definition blocks and arguments to "exec()" and "eval()" are
special in the context of name resolution. A class definition is an
executable statement that may use and define names. These references
follow the normal rules for name resolution with an exception that
unbound local variables are looked up in the global namespace. The
namespace of the class definition becomes the attribute dictionary of
the class. The scope of names defined in a class block is limited to
the class block; it does not extend to the code blocks of methods.
This includes comprehensions and generator expressions, but it does
not include annotation scopes, which have access to their enclosing
class scopes. This means that the following will fail:

   class A:
       a = 42
       b = list(a + i for i in range(10))

However, the following will succeed:

   class A:
       type Alias = Nested
       class Nested: pass

   print(A.Alias.__value__)  # <type 'A.Nested'>


4.2.3. Annotation scopes
------------------------

*Annotations*, type parameter lists and "type" statements introduce
*annotation scopes*, which behave mostly like function scopes, but
with some exceptions discussed below.

Annotation scopes are used in the following contexts:

* *Function annotations*.

* *Variable annotations*.

* Type parameter lists for generic type aliases.

* Type parameter lists for generic functions. A generic function's
  annotations are executed within the annotation scope, but its
  defaults and decorators are not.

* Type parameter lists for generic classes. A generic class's base
  classes and keyword arguments are executed within the annotation
  scope, but its decorators are not.

* The bounds, constraints, and default values for type parameters
  (lazily evaluated).

* The value of type aliases (lazily evaluated).

Annotation scopes differ from function scopes in the following ways:

* Annotation scopes have access to their enclosing class namespace. If
  an annotation scope is immediately within a class scope, or within
  another annotation scope that is immediately within a class scope,
  the code in the annotation scope can use names defined in the class
  scope as if it were executed directly within the class body. This
  contrasts with regular functions defined within classes, which
  cannot access names defined in the class scope.

* Expressions in annotation scopes cannot contain "yield", "yield
  from", "await", or ":=" expressions. (These expressions are allowed
  in other scopes contained within the annotation scope.)

* Names defined in annotation scopes cannot be rebound with "nonlocal"
  statements in inner scopes. This includes only type parameters, as
  no other syntactic elements that can appear within annotation scopes
  can introduce new names.

* While annotation scopes have an internal name, that name is not
  reflected in the *qualified name* of objects defined within the
  scope. Instead, the "__qualname__" of such objects is as if the
  object were defined in the enclosing scope.

Added in version 3.12: Annotation scopes were introduced in Python
3.12 as part of **PEP 695**.

バージョン 3.13 で変更: Annotation scopes are also used for type
parameter defaults, as introduced by **PEP 696**.

バージョン 3.14 で変更: Annotation scopes are now also used for
annotations, as specified in **PEP 649** and **PEP 749**.


4.2.4. Lazy evaluation
----------------------

Most annotation scopes are *lazily evaluated*. This includes
annotations, the values of type aliases created through the "type"
statement, and the bounds, constraints, and default values of type
variables created through the type parameter syntax. This means that
they are not evaluated when the type alias or type variable is
created, or when the object carrying annotations is created. Instead,
they are only evaluated when necessary, for example when the
"__value__" attribute on a type alias is accessed.

例:

   >>> type Alias = 1/0
   >>> Alias.__value__
   Traceback (most recent call last):
     ...
   ZeroDivisionError: division by zero
   >>> def func[T: 1/0](): pass
   >>> T = func.__type_params__[0]
   >>> T.__bound__
   Traceback (most recent call last):
     ...
   ZeroDivisionError: division by zero

Here the exception is raised only when the "__value__" attribute of
the type alias or the "__bound__" attribute of the type variable is
accessed.

This behavior is primarily useful for references to types that have
not yet been defined when the type alias or type variable is created.
For example, lazy evaluation enables creation of mutually recursive
type aliases:

   from typing import Literal

   type SimpleExpr = int | Parenthesized
   type Parenthesized = tuple[Literal["("], Expr, Literal[")"]]
   type Expr = SimpleExpr | tuple[SimpleExpr, Literal["+", "-"], Expr]

Lazily evaluated values are evaluated in annotation scope, which means
that names that appear inside the lazily evaluated value are looked up
as if they were used in the immediately enclosing scope.

Added in version 3.12.


4.2.5. 組み込みと制限付きの実行
-------------------------------

ユーザは "__builtins__" に触れるべきではありません; これは厳密に実装の
詳細です。組み込みの名前空間の中の値をオーバーライドしたいユーザは、
"builtins" モジュールを "import" して、その属性を適切に変更するべきで
す。

あるコードブロックの実行に関連する組み込み名前空間は、実際にはコードブ
ロックのグローバル名前空間から名前 "__builtins__" を検索することで見つ
かります; "__builtins__"  は辞書かモジュールでなければなりません (後者
の場合はモジュールの辞書が使われます)。デフォルトでは、 "__main__" モ
ジュール中においては、 "__builtins__" は組み込みモジュール "builtins"
です; それ以外の任意のモジュールにおいては、 "__builtins__" は
"builtins" モジュール自身の辞書のエイリアスです。


4.2.6. 動的な機能とのやりとり
-----------------------------

自由変数の名前解決はコンパイル時でなく実行時に行われます。つまり、以下
のコードは42を出力します:

   i = 10
   def f():
       print(i)
   i = 42
   f()

"eval()" と "exec()" 関数は、名前の解決に、現在の環境の全てを使えるわ
けではありません。名前は呼び出し側のローカルやグローバル名前空間で解決
できます。自由変数は最内名前空間ではなく、グローバル名前空間から解決さ
れます。 [1] "exec()" と "eval()" 関数にはオプションの引数があり、グロ
ーバルとローカル名前空間をオーバライドできます。名前空間が一つしか指定
されなければ、両方の名前空間として使われます。


4.3. 例外
=========

例外とは、コードブロックの通常の制御フローを中断して、エラーやその他の
例外的な状況を処理できるようにするための手段です。例外はエラーが検出さ
れた時点で *送出 (raise)* されます; 例外は、エラーが発生部の周辺のコー
ドブロックか、エラーが発生したコードブロック直接または間接的に呼び出し
ているコードブロックで *処理 (handle)* することができます。

Python インタプリタは、ランタイムエラー (ゼロ除算など) が検出されると
例外を送出します。Python プログラムから、 "raise" 文を使って明示的に例
外を送出することもできます。例外ハンドラ (exception handler) は、
"try" ... "except" 文で指定することができます。 "try" 文の "finally"
節を使うとクリーンアップコード (cleanup code) を指定できます。このコー
ドは例外は処理しませんが、先行するコードブロックで例外が起きても起きな
くても実行されます。

Python は、エラー処理に "プログラムの終了 (termination)" モデルを用い
ています: 例外ハンドラは、プログラムに何が発生したかを把握することがで
き、ハンドラの外側のレベルに処理を継続することはできますが、(問題のあ
ったコード部分を最初から実行しなおすのでない限り) エラーの原因を修復し
たり、実行に失敗した操作をやり直すことはできません。

例外が全く処理されないとき、インタプリタはプログラムの実行を終了させる
か、対話メインループに処理を戻します。 どちらの場合も、例外が
"SystemExit" でなければ、スタックのトレースバックを出力します。

例外は、クラスインスタンスによって識別されます。 "except" 節はインスタ
ンスのクラスにもとづいて選択されます: これはインスタンスのクラスか、そ
の *非仮想基底クラス* を参照します。このインスタンスはハンドラによって
受け取られ、例外条件に関する追加情報を伝えることができます。

注釈:

  例外のメッセージは、Python API 仕様には含まれていません。メッセージ
  の内容は、ある Python のバージョンと次のバージョンの間で警告なしに変
  更される可能性があるので、複数バージョンのインタプリタで動作するよう
  なコードは、例外メッセージの内容に依存させるべきではありません。

"try" 文については、 try 文 節、 "raise" 文については raise 文 節も参
照してください。


4.4. Runtime Components
=======================


4.4.1. General Computing Model
------------------------------

Python's execution model does not operate in a vacuum.  It runs on a
host machine and through that host's runtime environment, including
its operating system (OS), if there is one.  When a program runs, the
conceptual layers of how it runs on the host look something like this:

      **host machine**
         **process** (global resources)
            **thread** (runs machine code)

Each process represents a program running on the host.  Think of each
process itself as the data part of its program.  Think of the process'
threads as the execution part of the program.  This distinction will
be important to understand the conceptual Python runtime.

The process, as the data part, is the execution context in which the
program runs.  It mostly consists of the set of resources assigned to
the program by the host, including memory, signals, file handles,
sockets, and environment variables.

Processes are isolated and independent from one another.  (The same is
true for hosts.)  The host manages the process' access to its assigned
resources, in addition to coordinating between processes.

Each thread represents the actual execution of the program's machine
code, running relative to the resources assigned to the program's
process.  It's strictly up to the host how and when that execution
takes place.

From the point of view of Python, a program always starts with exactly
one thread.  However, the program may grow to run in multiple
simultaneous threads.  Not all hosts support multiple threads per
process, but most do.  Unlike processes, threads in a process are not
isolated and independent from one another.  Specifically, all threads
in a process share all of the process' resources.

The fundamental point of threads is that each one does *run*
independently, at the same time as the others.  That may be only
conceptually at the same time ("concurrently") or physically ("in
parallel").  Either way, the threads effectively run at a non-
synchronized rate.

注釈:

  That non-synchronized rate means none of the process' memory is
  guaranteed to stay consistent for the code running in any given
  thread.  Thus multi-threaded programs must take care to coordinate
  access to intentionally shared resources.  Likewise, they must take
  care to be absolutely diligent about not accessing any *other*
  resources in multiple threads; otherwise two threads running at the
  same time might accidentally interfere with each other's use of some
  shared data.  All this is true for both Python programs and the
  Python runtime.The cost of this broad, unstructured requirement is
  the tradeoff for the kind of raw concurrency that threads provide.
  The alternative to the required discipline generally means dealing
  with non-deterministic bugs and data corruption.


4.4.2. Python Runtime Model
---------------------------

The same conceptual layers apply to each Python program, with some
extra data layers specific to Python:

      **host machine**
         **process** (global resources)
            Python global runtime (*state*)
               Python interpreter (*state*)
                  **thread** (runs Python bytecode and "C-API")
                     Python thread *state*

At the conceptual level: when a Python program starts, it looks
exactly like that diagram, with one of each.  The runtime may grow to
include multiple interpreters, and each interpreter may grow to
include multiple thread states.

注釈:

  A Python implementation won't necessarily implement the runtime
  layers distinctly or even concretely.  The only exception is places
  where distinct layers are directly specified or exposed to users,
  like through the "threading" module.

注釈:

  The initial interpreter is typically called the "main" interpreter.
  Some Python implementations, like CPython, assign special roles to
  the main interpreter.Likewise, the host thread where the runtime was
  initialized is known as the "main" thread.  It may be different from
  the process' initial thread, though they are often the same.  In
  some cases "main thread" may be even more specific and refer to the
  initial thread state. A Python runtime might assign specific
  responsibilities to the main thread, such as handling signals.

As a whole, the Python runtime consists of the global runtime state,
interpreters, and thread states.  The runtime ensures all that state
stays consistent over its lifetime, particularly when used with
multiple host threads.

The global runtime, at the conceptual level, is just a set of
interpreters.  While those interpreters are otherwise isolated and
independent from one another, they may share some data or other
resources.  The runtime is responsible for managing these global
resources safely.  The actual nature and management of these resources
is implementation-specific.  Ultimately, the external utility of the
global runtime is limited to managing interpreters.

In contrast, an "interpreter" is conceptually what we would normally
think of as the (full-featured) "Python runtime".  When machine code
executing in a host thread interacts with the Python runtime, it calls
into Python in the context of a specific interpreter.

注釈:

  The term "interpreter" here is not the same as the "bytecode
  interpreter", which is what regularly runs in threads, executing
  compiled Python code.In an ideal world, "Python runtime" would refer
  to what we currently call "interpreter".  However, it's been called
  "interpreter" at least since introduced in 1997 (CPython:a027efa5b).

Each interpreter completely encapsulates all of the non-process-
global, non-thread-specific state needed for the Python runtime to
work. Notably, the interpreter's state persists between uses.  It
includes fundamental data like "sys.modules".  The runtime ensures
multiple threads using the same interpreter will safely share it
between them.

A Python implementation may support using multiple interpreters at the
same time in the same process.  They are independent and isolated from
one another.  For example, each interpreter has its own "sys.modules".

For thread-specific runtime state, each interpreter has a set of
thread states, which it manages, in the same way the global runtime
contains a set of interpreters.  It can have thread states for as many
host threads as it needs.  It may even have multiple thread states for
the same host thread, though that isn't as common.

Each thread state, conceptually, has all the thread-specific runtime
data an interpreter needs to operate in one host thread.  The thread
state includes the current raised exception and the thread's Python
call stack.  It may include other thread-specific resources.

注釈:

  The term "Python thread" can sometimes refer to a thread state, but
  normally it means a thread created using the "threading" module.

Each thread state, over its lifetime, is always tied to exactly one
interpreter and exactly one host thread.  It will only ever be used in
that thread and with that interpreter.

Multiple thread states may be tied to the same host thread, whether
for different interpreters or even the same interpreter.  However, for
any given host thread, only one of the thread states tied to it can be
used by the thread at a time.

Thread states are isolated and independent from one another and don't
share any data, except for possibly sharing an interpreter and objects
or other resources belonging to that interpreter.

Once a program is running, new Python threads can be created using the
"threading" module (on platforms and Python implementations that
support threads).  Additional processes can be created using the "os",
"subprocess", and "multiprocessing" modules. Interpreters can be
created and used with the "interpreters" module.  Coroutines (async)
can be run using "asyncio" in each interpreter, typically only in a
single thread (often the main thread).

-[ 脚注 ]-

[1] この制限は、上記の操作によって実行されるコードが、モジュールをコン
    パイルしたときには利用できないために起こります。
