4. 실행 모델

4.1. 프로그램의 구조

파이썬 프로그램은 코드 블록으로 만들어집니다. 블록 (block) 은 한 단위로 실행되는 한 조각의 파이썬 프로그램 텍스트입니다. 다음과 같은 것들이 블록입니다: 모듈, 함수 바디, 클래스 정의. 대화형으로 입력되는 각 명령은 블록입니다. 스크립트 파일(표준 입력을 통해 인터프리터로 제공되는 파일이나 인터프리터에 명령행 인자로 지정된 파일)은 코드 블록입니다. 스크립트 명령(-c 옵션으로 인터프리터 명령행에 지정된 명령)은 코드 블록입니다. -m 인자를 사용하여 명령 줄에서 최상위 수준 스크립트로 (모듈 __main__으로) 실행되는 모듈도 코드 블록입니다. 내장함수 eval() 과 exec() 로 전달되는 문자열 인자도 코드 블록입니다.

코드 블록은 실행 프레임 (execution frame) 에서 실행됩니다. 프레임은 몇몇 관리를 위한 정보(디버깅에 사용됩니다)를 포함하고, 코드 블록의 실행이 끝난 후에 어디서 어떻게 실행을 계속할 것인지를 결정합니다.

4.2. 이름과 연결(binding)

4.2.1. 이름의 연결

이름 (Names) 은 객체를 가리킵니다. 이름은 이름 연결 연산 때문에 만들어집니다.

The following constructs bind names:

• formal parameters to functions,

• class definitions,

• function definitions,

• assignment expressions,

• 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 statements.

• 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 문에 나오는 대상 역시 이 목적에서 연결된 것으로 간주합니다(실제 의미가 이름을 연결 해제하는 것이기는 해도).

각 대입이나 임포트 문은 클래스나 함수 정의 때문에 정의되는 블록 내에 등장할 수 있고, 모듈 수준(최상위 코드 블록)에서 등장할 수도 있습니다.

만약 이름이 블록 내에서 연결되면, nonlocal 이나 global 로 선언되지 않는 이상, 그 블록의 지역 변수입니다. 만약 이름이 모듈 수준에서 연결되면, 전역 변수입니다. (모듈 코드 블록의 변수들 지역이면서 전역입니다.) 만약 변수가 코드 블록에서 사용되지만, 거기에서 정의되지 않았으면 자유 변수 (free variable) 입니다.

프로그램 텍스트에 등장하는 각각의 이름들은 다음에 나오는 이름 검색(name resolution) 규칙에 따라 확정되는 이름의 연결 (binding) 을 가리킵니다.

4.2.2. 이름의 검색(resolution)

스코프 (scope) 는 블록 내에서 이름의 가시성(visibility)을 정의합니다. 지역 변수가 블록에서 정의되면, 그것의 스코프는 그 블록을 포함합니다. 만약 정의가 함수 블록에서 이루어지면, 포함된 블록이 그 이름에 대해 다른 결합을 만들지 않는 이상, 스코프는 정의하고 있는 것 안에 포함된 모든 블록으로 확대됩니다.

이름이 코드 블록 내에서 사용될 때, 가장 가깝게 둘러싸고 있는 스코프에 있는 것으로 검색됩니다. 코드 블록이 볼 수 있는 모든 스코프의 집합을 블록의 환경 (environment) 이라고 부릅니다.

이름이 어디에서도 발견되지 않으면 NameError 예외가 발생합니다. 만약 현재 스코프가 함수 스코프이고, 그 이름이 사용되는 시점에 아직 연결되지 않은 지역 변수면 UnboundLocalError 예외가 발생합니다. UnboundLocalError 는 NameError 의 서브 클래스입니다.

If a name binding operation occurs anywhere within a code block, all uses of the name within the block are treated as references to the current block. This can lead to errors when a name is used within a block before it is bound. This rule is subtle. Python lacks declarations and allows name binding operations to occur anywhere within a code block. The local variables of a code block can be determined by scanning the entire text of the block for name binding operations. See the FAQ entry on UnboundLocalError for examples.

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. 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.

모듈의 이름 공간은 모듈이 처음 임포트될 때 자동으로 만들어집니다. 스크립트의 메인 모듈은 항상 __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

Type parameter lists and type statements introduce annotation scopes, which behave mostly like function scopes, but with some exceptions discussed below. Annotations currently do not use annotation scopes, but they are expected to use annotation scopes in Python 3.13 when PEP 649 is implemented.

Annotation scopes are used in the following contexts:

• 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 and constraints for type variables (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 __qualname__ of objects defined within the scope. Instead, the __qualname__ of such objects is as if the object were defined in the enclosing scope.

버전 3.12에 추가: Annotation scopes were introduced in Python 3.12 as part of PEP 695.

4.2.4. Lazy evaluation

The values of type aliases created through the type statement are lazily evaluated. The same applies to the bounds and constraints 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. Instead, they are only evaluated when doing so is necessary to resolve an attribute access.

Example:

>>> 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.

버전 3.12에 추가.

4.2.5. builtins 와 제한된 실행

CPython 구현 상세: 사용자는 __builtins__ 를 건드리지 말아야 합니다; 이것은 구현 세부사항입니다. 내장 이름 공간의 값을 변경하고 싶은 사용자는 builtins 모듈을 import 하고 그것의 어트리뷰트를 적절하게 수정해야 합니다.

코드 블록의 실행과 연관된 내장 이름 공간은, 사실 전역 이름 공간의 이름 __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. 예외

예외는 에러나 예외적인 조건을 처리하기 위해 코드 블록의 일반적인 제어 흐름을 깨는 수단입니다. 에러가 감지된 지점에서 예외를 일으킵니다(raised); 둘러싼 코드 블록이나 직접적 혹은 간접적으로 에러가 발생한 코드 블록을 호출한 어떤 코드 블록에서건 예외는 처리될 수 있습니다.

파이썬 인터프리터는 실행 시간 에러(0으로 나누는 것 같은)를 감지할 때 예외를 일으킵니다. 파이썬 프로그램은 raise 문을 사용해서 명시적으로 예외를 일으킬 수 있습니다. 예외 처리기는 try … except 문으로 지정됩니다. 그런 문장에서 finally 구는 정리(cleanup) 코드를 지정하는 데 사용되는데, 예외를 처리하는 것이 아니라 앞선 코드에서 예외가 발생하건 그렇지 않건 실행됩니다.

파이썬은 에러 처리에 “종결 (termination)” 모델을 사용합니다; 예외 처리기가 뭐가 발생했는지 발견할 수 있고, 바깥 단계에서 실행을 계속할 수는 있지만, 에러의 원인을 제거한 후에 실패한 연산을 재시도할 수는 없습니다(문제의 코드 조각을 처음부터 다시 시작시키는 것은 예외입니다).

예외가 어디서도 처리되지 않을 때, 인터프리터는 프로그램의 실행을 종료하거나, 대화형 메인 루프로 돌아갑니다. 두 경우 모두, 예외가 SystemExit 인 경우를 제외하고, 스택 트레이스백을 인쇄합니다.

Exceptions are identified by class instances. The except clause is selected depending on the class of the instance: it must reference the class of the instance or a non-virtual base class thereof. The instance can be received by the handler and can carry additional information about the exceptional condition.

참고

예외 메시지는 파이썬 API 일부가 아닙니다. 그 내용은 파이썬의 버전이 바뀔 때 경고 없이 변경될 수 있고, 코드는 여러 버전의 인터프리터에서 실행될 수 있는 코드는 이것에 의존하지 말아야 합니다.

섹션 try 문 에서 try 문, raise 문 에서 raise 문에 대한 설명이 제공됩니다.

각주

[1]

이 한계는 이 연산들 때문에 실행되는 코드가 모듈이 컴파일되는 시점에는 존재하지 않았기 때문입니다.