6. 표현식¶

이 장은 파이썬에서 사용되는 표현식 요소들의 의미를 설명한다.

문법 유의 사항: 여기와 이어지는 장에서는, 구문 분석이 아니라 문법을 설명하기 위해 확장 BNF 표기법을 사용한다. 문법 규칙이 다음과 같은 형태를 가지고,

name ::=  othername

뜻(semantics)을 주지 않으면, 이 형태의 name 의 뜻은 othername 과 같다.

6.1. 산술 변환¶

다음에 나오는 산술 연산자의 설명이 《숫자 인자들은 공통 형으로 변환된다》라는 구절을 사용할 때, 내장형의 연산자 구현이 다음과 같이 동작한다는 뜻이다:

어느 한 인자가 복소수면 다른 하나는 복소수로 변환된다;
그렇지 않고, 어느 한 인자가 실수면, 다른 하나는 실수로 변환된다;
그렇지 않으면, 두 인자는 모두 정수여야 하고, 변환은 필요 없다.

어떤 연산자들(예를 들어, 〈%〉 연산자의 왼쪽 인자로 주어지는 문자열)에 대해서는 몇 가지 추가의 규칙이 적용된다. 확장(extension)은 그들 자신의 변환 규칙을 정의해야 한다.

6.2. 아톰 (Atoms)¶

아톰은 표현식의 가장 기본적인 요소다. 가장 간단한 아톰은 식별자와 리터럴이다. 괄호, 꺾쇠괄호, 중괄호로 둘러싸인 형태도 문법적으로 아톰으로 분류된다. 아톰의 문법은 이렇다:

atom      ::=  identifier | literal | enclosure
enclosure ::=  parenth_form | list_display | dict_display | set_display
               | generator_expression | yield_atom

6.2.1. 식별자 (이름)¶

아톰으로 등장하는 식별자는 이름이다. 구문 분석에 대해서는 식별자와 키워드 섹션을, 이름과 연결에 대한 문서는 이름과 연결(binding) 섹션을 보면 된다.

이름이 객체에 연결될 때, 아톰의 값을 구하면 객체가 나온다. 이름이 연결되지 않았을 때, 값을 구하려고 하면 NameError 예외가 일어난다.

비공개 이름 뒤섞기(private name mangling): 클래스 정의에 등장하는 식별자가 두 개나 그 이상의 밑줄로 시작하고, 두 개나 그 이상의 밑줄로 끝나지 않으면, 그 클래스의 비공개 이름(private name) 으로 간주한다. 비공개 이름은 그 들을 위한 코드가 만들어지기 전에 더 긴 형태로 변환된다. 이 변환은 그 이름의 앞에 클래스 이름을 삽입하는데, 클래스 이름의 처음에 오는 모든 밑줄을 제거한 후, 하나의 밑줄을 추가한다. 예를 들어, Ham 이라는 이름의 클래스에 식별자 __spam 이 등장하면, _Ham__spam 으로 변환된다. 이 변환은 식별자가 사용되는 문법적인 문맥에 무관하다. 변환된 이름이 극단적으로 길면(255자보다 길면), 구현이 정의한 잘라내기가 발생할 수 있다. 클래스 이름이 밑줄로만 구성되어 있으면, 변환은 일어나지 않는다.

6.2.2. 리터럴 (Literals)¶

파이썬은 문자열과 바이트열 리터럴과 여러 가지 숫자 리터럴들을 지원한다:

literal ::=  stringliteral | bytesliteral
             | integer | floatnumber | imagnumber

리터럴의 값을 구하면 주어진 형(문자열, 바이트열, 정수, 실수, 복소수)과 주어진 값을 갖는 객체가 나온다. 실수와 복소수의 경우는 근삿값일 수 있다. 자세한 내용은 리터럴 섹션을 보면 된다.

모든 리터럴은 불변 데이터형에 대응하기 때문에, 객체의 아이덴티티는 값 보다 덜 중요하다. 같은 값의 리터럴에 대해 반복적으로 값을 구하면 (프로그램 텍스트의 같은 장소에 있거나 다른 장소에 있을 때) 같은 객체를 얻을 수도 있고, 같은 값의 다른 객체를 얻을 수도 있다.

6.2.3. 괄호 안에 넣은 형¶

괄호 안에 넣은 형은, 괄호로 둘러싸인 생략 가능한 표현식 목록이다:

parenth_form ::=  "(" [starred_expression] ")"

괄호 안에 넣은 표현식 목록은, 무엇이건 그 표현식 목록이 산출하는 것이 된다: 목록이 적어도 하나의 쉼표를 포함하면, 튜플이 된다; 그렇지 않으면 표현식 목록을 구성한 단일 표현식이 된다.

빈 괄호 쌍은 빈 튜플 객체를 만든다. 튜플은 불변이기 때문에 리터럴의 규칙이 적용된다 (즉, 두 개의 빈 튜플은 같은 객체일 수도 있고 그렇지 않을 수도 있다).

튜플이 괄호에 의해 만들어지는 것이 아니라, 쉼표 연산자의 사용 때문이라는 것에 주의해야 한다. 예외는 빈 튜플인데, 괄호가 필요하다 — 표현식에서 괄호 없는 《없음(nothing)》을 허락하는 것은 모호함을 유발하고 자주 발생하는 오타들이 잡히지 않은 채로 남게 할 것이다.

6.2.4. 리스트, 집합, 딕셔너리의 디스플레이(display)¶

리스트, 집합, 딕셔너리를 구성하기 위해, 파이썬은 《디스플레이(displays)》라고 부르는 특별한 문법을 각기 두 가지 스타일로 제공한다:

컨테이너의 내용을 명시적으로 나열하거나,
일련의 루프와 필터링 지시들을 통해 계산되는데, 컴프리헨션 (comprehension) 이라고 불린다.

컴프리헨션의 공통 문법 요소들은 이렇다:

comprehension ::=  expression comp_for
comp_for      ::=  [ASYNC] "for" target_list "in" or_test [comp_iter]
comp_iter     ::=  comp_for | comp_if
comp_if       ::=  "if" expression_nocond [comp_iter]

컴프리헨션은 하나의 표현식과 그 뒤를 따르는 최소한 하나의 for 절과 없거나 여러 개의 for 또는 if 절로 구성된다. 이 경우, 새 컨테이너의 요소들은 각 for 또는 if 절이 왼쪽에서 오른쪽으로 중첩된 블록을 이루고, 가장 안쪽에 있는 블록에서 표현식의 값을 구해서 만들어낸 것들이다.

컴프리헨션은 별도의 스코프(scope)에서 실행되기 때문에, 타깃 목록에서 대입된 이름들은 둘러싼 스코프로 《누수(leak)》되지 않음에 주의해야 한다.

파이썬 3.6부터, async def 함수에서는, 비동기 이터레이터 를 탐색하기 위해 async for 를 사용할 수 있다. async def 함수에 있는 컴프리헨션은 처음에 나오는 표현식뒤에 for 나 async for 절이 올 수 있고, 추가의 for 나 async for 절이 올 수 있고, await 표현식 또한 사용할 수 있다. 컴프리헨션이 async for 절이나 await 표현식을 포함하면 비동기 컴프리헨션 (asynchronous comprehension) 이라고 불린다. 비동기 컴프리헨션은 그것이 등장한 코루틴 함수의 실행을 일시 중지시킬 수 있다. PEP 530 를 참고하라.

6.2.5. 리스트 디스플레이¶

리스트 디스플레이는 꺾쇠괄호(square brackets)로 둘러싸인 표현식의 나열인데 비어있을 수 있다:

list_display ::=  "[" [starred_list | comprehension] "]"

리스트 디스플레이는 리스트 객체를 만드는데, 그 내용은 표현식의 목록이나 컴프리헨션으로 지정할 수 있다. 쉼표로 분리된 표현식의 목록이 제공될 때, 그 요소들은 왼쪽에서 오른쪽으로 값이 구해지고, 그 순서대로 리스트 객체에 삽입된다. 컴프리헨션이 제공될 때, 리스트는 컴프리헨션으로 만들어지는 요소들로 구성된다.

6.2.6. 집합 디스플레이¶

집합 디스플레이는 중괄호(curly braces)로 표시되고, 키와 값을 분리하는 콜론(colon)이 없는 것으로 딕셔너리 디스플레이와 구분될 수 있다.

set_display ::=  "{" (starred_list | comprehension) "}"

집합 디스플레이는 새 가변 집합 객체를 만드는데, 그 내용은 표현식의 시퀀스나 컴프리헨션으로 지정된다. 쉼표로 분리된 표현식의 목록이 제공될 때, 그 요소들은 왼쪽에서 오른쪽으로 값이 구해지고, 집합 객체에 더해진다. 컴프리헨션이 제공될 때, 집합은 컴프리헨션으로 만들어지는 요소들로 구성된다.

빈 집합은 {} 으로 만들어질 수 없다; 이 리터럴은 빈 딕셔너리를 만든다.

6.2.7. 딕셔너리 디스플레이¶

딕셔너리 디스플레이는 중괄호(curly braces)로 둘러싸인 키/데이터 쌍의 나열인데 비어있을 수 있다:

dict_display       ::=  "{" [key_datum_list | dict_comprehension] "}"
key_datum_list     ::=  key_datum ("," key_datum)* [","]
key_datum          ::=  expression ":" expression | "**" or_expr
dict_comprehension ::=  expression ":" expression comp_for

딕셔너리 디스플레이는 새 딕셔너리 객체를 만든다.

쉼표로 분리된 키/데이터 쌍의 시퀀스가 주어질 때, 그것들은 왼쪽에서 오른쪽으로 값이 구해지고 딕셔너리의 엔트리들을 정의한다: 각 키 객체는 딕셔너리에 대응하는 데이터를 저장하는 데 키로 사용된다. 이것은 키/값 목록에서 같은 키를 여러 번 지정할 수 있다는 뜻인데, 그 키의 최종 딕셔너리 값은 마지막에 주어진 것이 된다.

두 개의 애스터리스크(asterisk) ** 는 딕셔너리 언 패킹(dictionary unpacking) 를 나타낸다. 피연산자는 매핑 이어야만 한다. 각 매핑 항목은 새 딕셔너리에 추가된다. 뒤에 오는 값들이 앞의 키/데이터 쌍이나 앞의 딕셔너리 언 패킹 때문에 설정된 값들을 교체한다.

버전 3.5에 추가: PEP 448 에서 처음 제안된 딕셔너리 디스플레이로의 언 패킹.

딕셔너리 컴프리헨션은, 리스트와 집합 컴프리헨션에 대비해서, 일반적인 《for》 와 《if》 절 앞에 콜론으로 분리된 두 개의 표현식을 필요로 한다. 컴프리헨션이 실행될 때, 만들어지는 키와 값 요소들이 만들어지는 순서대로 딕셔너리에 삽입된다.

킷값의 형에 대한 제약은 앞의 섹션 표준형 계층 에서 나열되었다. (요약하자면, 키 형은 해시 가능 해야 하는데, 모든 가변 객체들이 제외된다.) 중복된 키 간의 충돌은 감지되지 않는다; 주어진 키에 대해 저장된 마지막 (구문상으로 디스플레이의 가장 오른쪽에 있는) 데이터가 우선한다.

6.2.8. 제너레이터 표현식 (Generator expressions)¶

제너레이터 표현식은 괄호로 둘러싸인 간결한 제너레이터 표기법이다.

generator_expression ::=  "(" expression comp_for ")"

제너레이터 표현식은 새 제너레이터 객체를 만든다. 문법은 꺾쇠괄호나 중괄호 대신 괄호로 둘러싸인다는 점만 제외하면 컴프리헨션과 같다.

제너레이터 표현식에 사용되는 변수들은 제너레이터 객체의 __next__() 메서드가 호출될 때 느긋하게(lazily) 값이 구해진다 (일반 제너레이터와 마찬가지다). 하지만, 가장 왼쪽의 for 절은 즉시 값이 구해져서, 그것으로 인해 발생하는 에러는 제너레이터 표현을 다루는 다른 어떤 코드들에서 발생하는 에러들보다 먼저 발견된다. 뒤따르는 for 절들은 앞의 for 루프에 종속되기 때문에 즉시 값을 구할 수 없다. 예를 들어: (x*y for x in range(10) for y in bar(x)).

단지 하나의 인자만 갖는 호출에서는 괄호를 생략할 수 있다. 자세한 내용은 호출 섹션을 보면 된다.

파이썬 3.6부터, 제너레이터가 async def 함수에서 등장하면, 비동기 컴프리헨션 처럼 async for 절과 await 표현식이 허락된다. 제너레이터 표현식이 async for 절이나 await 표현식을 포함하면 비동기 제너레이터 표현식 (asynchronous generator expression) 이라고 불린다. 비동기 제너레이터 표현식은 새 비동기 제너레이터 객체를 만드는데 이것은 비동기 이터레이터다 (비동기 이터레이터(Asynchronous Iterators) 를 참고하라).

6.2.9. 일드 표현식(Yield expressions)¶

yield_atom       ::=  "(" yield_expression ")"
yield_expression ::=  "yield" [expression_list | "from" expression]

일드 표현식은 제너레이터 함수나 비동기 제너레이터 함수를 정의할 때 사용되고, 그래서 함수 정의의 바디에서만 사용될 수 있다. 함수의 바디에서 일드 표현식을 사용하는 것은 함수를 제너레이터로 만들고, async def 함수의 바디에서 사용하는 것은 그 코루틴 함수를 비동기 제너레이터로 만든다. 예를 들어:

def gen():  # defines a generator function
    yield 123

async def agen(): # defines an asynchronous generator function
    yield 123

제너레이터 함수는 다음에서 설명한다. 반면에 비동기 제너레이터 함수는 비동기 제너레이터 함수 섹션에서 별도로 설명한다.

제너레이터 함수가 호출될 때, 제너레이터로 알려진 이터레이터를 돌려준다. 그러면 그 제너레이터가 제너레이터 함수의 실행을 제어한다. 제너레이터의 메서드들 중 하나가 호출될 때 실행이 시작된다. 그 시점에, 실행은 첫 번째 일드 표현식까지 진행한 후, 거기에서 다시 일시 중지(suspend)하고 제너레이터의 호출자에게 expression_list 의 값을 돌려준다. 일시 중지된다는 것은, 모든 지역 상태가 보존된다는 뜻인데, 지역 변수들의 현재 연결들, 명령 포인터(instruction pointer), 내부 연산 스택(internal evaluation stack), 모든 예외 처리 상태가 포함된다. 제너레이터의 메서드들 중 하나를 호출해서 실행이 재개될 때, 함수는 마치 일드 표현식이 단지 또 하나의 외부 호출인 것처럼 진행할 수 있다. 재개된 후에 일드 표현식의 값은 실행을 재개하도록 만든 메서드에 달려있다. (보통 for 나 next() 내장을 통해) __next__() 가 사용되었다면 결과는 None 이다. 그렇지 않고, send() 가 사용되었다면, 결과는 그 메서드로 전달된 값이다.

이 모든 것들은 제너레이터 함수를 코루틴과 아주 비슷하게 만든다; 여러 번 결과를 만들고, 하나 이상의 진입 지점을 갖고 있으며, 실행이 일시 중지될 수 있다. 유일한 차이점은 제너레이터 함수는 yield 한 후에 실행이 어디에서 계속되어야 하는지를 제어할 수 없다는 점이다; 제어는 항상 제너레이터의 호출자로 전달된다.

일드 표현식은 try 구조물의 어디에서건 허락된다. 제너레이터가 (참조 횟수가 0이 되거나 가비지 수거됨으로써) 파이널라이즈(finalize)되기 전에 재개되지 않으면, 제너레이터-이터레이터의 close() 메서드가 호출되어, 대기 중인 finally 절이 실행되도록 허락한다.

yield from <expr> 이 사용될 때, 제공된 표현식을 서브 이터레이터(subiterator)로 취급한다. 서브 이터레이터가 만드는 모든 값은 현재 제너레이터 메서드의 호출자에게 바로 전달된다. send() 로 전달된 모든 값과 throw() 로 전달된 모든 예외는 밑에 있는(underlying) 이터레이터가 해당 메서드를 갖고 있다면 그곳으로 전달된다. 그렇지 않다면, send() 는 AttributeError 나 TypeError 를 일으키지만, throw() 는 전달된 예외를 즉시 일으킨다.

밑에 있는 이러레이터가 완료될 때, 발생하는 StopIteration 인스턴스의 value 어트리뷰트는 일드 표현식의 값이 된다. StopIteration 를 일으킬 때 명시적으로 설정되거나, 서브 이터레이터가 제너레이터일 경우는 자동으로 이루어진다 (서브 제너레이터가 값을 돌려(return)줌으로써).

버전 3.3에서 변경: 서브 이터레이터로 제어 흐름을 위임하는 yield from <expr> 를 추가했다.

일드 표현식이 대입문의 우변에 홀로 나온다면 괄호를 생략할 수 있다.

PEP 255 - 간단한 제너레이터: 파이썬에 제너레이터와 yield 문을 추가하는 제안.
PEP 342 - 개선된 제너레이터를 통한 코루틴: 제너레이터의 API와 문법을 개선해서, 간단한 코루틴으로 사용할 수 있도록 만드는 제안.
PEP 380 - 서브 제너레이터로 위임하는 문법: yield_from 문법을 도입해서, 서브 제너레이터로의 위임을 쉽게 만드는 제안.
PEP 525 - Asynchronous Generators: The proposal that expanded on PEP 492 by adding generator capabilities to coroutine functions.

6.2.9.1. 제너레이터-이터레이터 메서드¶

이 서브섹션은 제너레이터 이터레이터의 메서드들을 설명한다. 제너레이터 함수의 실행을 제어하는데 사용될 수 있다.

제너레이터가 이미 실행 중일 때 아래에 나오는 메서드들을 호출하면 ValueError 예외를 일으키는 것에 주의해야 한다.

generator.__next__()¶

제너레이터 함수의 실행을 시작하거나 마지막으로 실행된 일드 표현식에서 재개한다. 제너레이터 함수가 __next__() 메서드로 재개될 때, 현재의 일드 표현식은 항상 None 값을 갖는다. 실행은 다음 일드 표현식까지 이어지는데, 그곳에서 제너레이터는 다시 일시 중지되고, expression_list 의 값을 __next__() 의 호출자에게 돌려준다. 제너레이터가 다른 값을 yield 하지 않고 종료되면 StopIteration 예외가 발생한다.

이 메서드는 보통 묵시적으로 호출된다, 예를 들어, for 루프나 내장 next() 함수에 의해.

generator.send(value)¶: 실행을 재개하고 제너레이터 함수로 값을 《보낸다(send)》. value 인자는 현재 일드 표현식의 값이 된다. send() 메서드는 제너레이터가 yield 하는 다음 값을 돌려주거나, 제너레이터가 다른 값을 yield 하지 않고 종료하면 StopIteration 을 일으킨다. send() 가 제너레이터를 시작시키도록 호출될 때, 값을 받을 일드 표현식이 없으므로, 인자로는 반드시 None 을 전달해야 한다.

generator.throw(type[, value[, traceback]])¶: 제너레이터가 일시 정지한 지점에서 type 형의 예외를 일으키고, 제너레이터 함수가 yield 하는 다음 값을 돌려준다. 제너레이터가 다른 값을 yield 하지 않고 종료하면 StopIteration 을 일으킨다. 제너레이터가 전달된 예외를 잡지 않거나, 다른 예외를 일으키면, 그 예외는 호출자로 퍼진다.

generator.close()¶: 제너레이터가 일시 정지한 지점에서 GeneratorExit 를 일으킨다. 그런 다음 제너레이터 함수가 우아하게(gracefully) 종료하거나, 이미 닫혔거나, (그 예외를 잡지 않음으로써) GeneratorExit 를 일으키면 close는 호출자로 돌아간다. 제너레이터가 값을 yield 하면 RuntimeError 가 발생한다. 제너레이터가 다른 예외를 일으키면, 호출자로 퍼진다. 제너레이터가 예외나 정상 종료로 인해 이미 종료되었다면, close() 는 아무런 일도 하지 않는다.

6.2.9.2. 사용 예¶

여기에 제너레이터와 제너레이터 함수의 동작을 시연하는 간단한 예가 있다:

>>> def echo(value=None):
...     print("Execution starts when 'next()' is called for the first time.")
...     try:
...         while True:
...             try:
...                 value = (yield value)
...             except Exception as e:
...                 value = e
...     finally:
...         print("Don't forget to clean up when 'close()' is called.")
...
>>> generator = echo(1)
>>> print(next(generator))
Execution starts when 'next()' is called for the first time.
1
>>> print(next(generator))
None
>>> print(generator.send(2))
2
>>> generator.throw(TypeError, "spam")
TypeError('spam',)
>>> generator.close()
Don't forget to clean up when 'close()' is called.

yield from 을 사용하는 예는, 《What’s New in Python.》 에 있는 PEP 380: Syntax for Delegating to a Subgenerator 을 보면 된다.

6.2.9.3. 비동기 제너레이터 함수¶

async def 를 사용한 함수나 메서드에서 일드 표현식의 존재는 그 함수를 비동기 제너레이터 함수로 정의한다.

비동기 제너레이터 함수가 호출되면, 비동기 제너레이터 객체로 알려진 비동기 이터레이터를 돌려준다. 그런 다음 그 객체는 제너레이터 함수의 실행을 제어한다. 비동기 제너레이터 객체는 보통 코루틴 함수의 async for 문에서 사용되는데, 제너레이터 객체가 for 문에서 사용되는 방식과 유사하다.

비동기 제너레이터의 메서드들 중 하나를 호출하면 어웨이터블 객체를 돌려주고, 이 객체를 await 할 때 실행이 시작된다. 그 시점에, 실행은 첫 번째 일드 표현식까지 진행한 후, 거기에서 다시 일시 중지(suspend)하고 await 중인 코루틴에게 expression_list 의 값을 돌려준다. 제너레이터에서처럼, 일시 중지된다는 것은, 모든 지역 상태가 보존된다는 뜻인데, 지역 변수들의 현재 연결들, 명령 포인터(instruction pointer), 내부 연산 스택(internal evaluation stack), 모든 예외 처리 상태가 포함된다. 비동기 제너레이터의 메서드가 돌려준 다음 객체를 await 해서 실행이 재개될 때, 함수는 마치 일드 표현식이 단지 또 하나의 외부 호출인 것처럼 진행할 수 있다. 재개된 후에 일드 표현식의 값은 실행을 재개하도록 만든 메서드에 달려있다. __anext__() 가 사용되었다면 결과는 None 이다. 그렇지 않고, asend() 가 사용되었다면, 결과는 그 메서드로 전달된 값이다.

비동기 제너레이터 함수에서, 일드 표현식은 try 구조물의 어디에서건 허락된다. 하지만, 비동기 제너레이터가 (참조 횟수가 0이 되거나 가비지 수거됨으로써) 파이널라이즈(finalize)되기 전에 재개되지 않으면, try 구조물 내의 일드 표현식은 대기 중인 finally 절을 실행하는 데 실패할 수 있다. 이 경우에, 비동기 제너레이터-이터레이터의 aclose() 를 호출하고, 그 결과로 오는 코루틴 객체를 실행해서, 대기 중인 finally 절이 실행되도록 하는 책임은, 비동기 제너레이터를 실행하는 이벤트 루프(event loop)나 스케쥴러(scheduler)에게 있다.

파이널리제이션을 처리하기 위해, 이벤트 루프는 파이널라이저(finalizer) 함수를 정의해야 하는데 비동기 제너레이터-이터레이터를 받아서 아마도 aclose() 를 호출하고 그 코루틴을 실행한다. 이 파이널라이저 는 sys.set_asyncgen_hooks() 을 호출해서 등록할 수 있다. 처음 탐색 될 때, 비동기 제너레이터-이터레이터는 파이널리제이션때 호출될 등록된 파이널라이저 를 저장할 것이다. 파이널라이저 메서드의 참조할만한 예는 Lib/asyncio/base_events.py 에 있는 asyncio.Loop.shutdown_asyncgens 구현을 보면 된다.

표현식 yield from <expr> 를 비동기 제너레이터 함수에서 사용하는 것은 문법 에러다.

6.2.9.4. 비동기 제너레이터-이터레이터 메서드¶

이 서브섹션은 비동기 제너레이터 이터레이터의 메서드를 설명하는데, 제너레이터 함수의 실행을 제어하는 데 사용된다.

coroutine agen.__anext__()¶

어웨이터블을 돌려주는데, 실행하면 비동기 제너레이터 함수의 실행을 시작하거나 마지막으로 실행된 일드 표현식에서 재개한다. 비동기 제너레이터 함수가 __anext__() 메서드로 재개될 때, 반환된 어웨이터블에서 현재의 일드 표현식은 항상 None 값을 갖고 반환된 어웨이터블을 실행하면 다음 일드 표현식까지 이어진다. 일드 표현식의 expression_list 의 값은 종료하는 코루틴이 일으킨 StopIteration 의 값이다. 비동기 제너레이터가 다른 값을 yield 하지 않고 종료되면, 비동기 탐색의 종료를 알리기 위해 어웨이터블이 대신 StopAsyncIteration 예외를 일으킨다.

이 메서드는 보통 async for 루프에 의해 묵시적으로 호출된다.

coroutine agen.asend(value)¶: 어웨이터블을 돌려주는데, 실행하면 비동기 제너레이터의 실행을 재개한다. 제너레이터의 send() 메서드 처럼, 이것은 값을 비동기 제너레이터 함수로 《보내(send)》고, value 인자는 현재 일드 표현식의 결과가 된다. asend() 메서드가 돌려주는 어웨이터블은 제너레이터가 yield 하는 다음 값을 발생시킨 StopIteration 의 값으로 돌려주거나, 비동기 제너레이터가 다른 값을 yield 하지 않고 종료하면 StopAsyncIteration 를 일으킨다. 비동기 제너레이터를 시작시키도록 asend() 가 호출될 때, 값을 받을 일드 표현식이 없으므로 인자를 None 으로 호출해야 한다.

coroutine agen.athrow(type[, value[, traceback]])¶: 어웨이터블을 돌려주는데, 비동기 제너레이터가 일시 중지한 지점에 type 형의 예외를 일으키고, 제너레이터 함수가 yield 한 다음 값을 발생하는 StopIteration 예외의 값으로 돌려준다. 비동기 제너레이터가 다른 값을 yield 하지 않고 종료하면, 어웨이터블에 의해 StopAsyncIteration 예외가 일어난다. 제너레이터 함수가 전달된 예외를 잡지 않거나, 다른 예외를 일으키면, 어웨이터블을 실행할 때 그 예외가 어웨이터블의 호출자에게 퍼진다.

coroutine agen.aclose()¶: 어웨이터블을 돌려주는데, 실행하면, 비동기 제너레이터 함수가 일시 정지한 지점으로 GeneratorExit 를 던진다. 만약 그 이후에 비동기 제너레이터 함수가 우아하게 (gracefully) 종료하거나, 이미 닫혔거나, (그 예외를 잡지 않음으로써) GeneratorExit 를 일으키면, 돌려준 어웨이터블은 StopIteration 예외를 일으킨다. 이어지는 비동기 제너레이터 호출이 돌려주는 추가의 어웨이터블들은 StopAsyncIteration 예외를 일으킨다. 만약 비동기 제너레이터가 값을 yield 하면 어웨이터블에 의해 RuntimeError 가 발생한다. 만약 비동기 제너레이터가 그 밖의 다른 예외를 일으키면, 어웨이터블의 호출자로 퍼진다. 만약 비동기 제너레이터가 예외나 정상 종료로 이미 종료했으면, 더 이어지는 aclose() 호출은 아무것도 하지 않는 어웨이터블을 돌려준다.

6.3. 프라이머리¶

프라이머리는 언어에서 가장 강하게 결합하는 연산들을 나타낸다. 문법은 이렇다:

primary ::=  atom | attributeref | subscription | slicing | call

6.3.1. 어트리뷰트 참조¶

어트리뷰트 참조는 마침표(period)와 이름이 뒤에 붙은 프라이머리다:

attributeref ::=  primary "." identifier

프라이머리는 값을 구했을 때 어트리뷰트 참조를 지원하는 형의 객체가 나와야 하는데, 대부분 객체가 이 상황에 해당한다. 이 객체는 그 이름을 식별자로 하는 어트리뷰트를 생산하도록 요청받는다. 이 생산은 __getattr__() 메서드를 재정의해서 커스터마이즈 할 수 있다. 이 어트리뷰트가 없으면, AttributeError 을 일으킨다. 그렇지 않으면, 생산된 객체의 형과 값은 그 객체에 의해 결정된다. 같은 어트리뷰트 참조의 값을 여러 번 구하면 각기 다른 객체가 얻어질 수 있다.

6.3.2. 서브스크립션(Subscriptions)¶

서브스크립션은 시퀀스(문자열, 튜플, 리스트)나 매핑 (딕셔너리) 객체의 항목을 선택한다:

subscription ::=  primary "[" expression_list "]"

프라이머리는 값을 구했을 때 서브스크립션을 지원하는 객체가 나와야 한다 (예를 들어, 리스트나 딕셔너리). 사용자 정의 객체들은 __getitem__() 메서드를 구현해서 서브스크립션을 지원할 수 있다.

내장 객체들의 경우, 서브스크립션을 지원하는 두 가지 종류의 객체들이 있다:

프라이머리가 매핑이면, 표현식 목록은 값을 구했을 때 매핑의 키 중 하나가 되어야 하고, 서브스크립션은 매핑에서 그 키에 대응하는 값을 선택한다. (표현식 목록은 정확히 하나의 항목을 가지는 경우만을 제외하고는 튜플이다.)

If the primary is a sequence, the expression list must evaluate to an integer or a slice (as discussed in the following section).

형식 문법은 시퀀스에서 음수 인덱스에 대해 특별히 규정하지 않는다; 하지만, 내장 시퀀스들은 모두 인덱스에 시퀀스의 길이를 더하는 것으로 음의 인덱스를 해석하는 __getitem__() 메서드를 제공한다 (그래서 x[-1] 은 x 의 마지막 항목을 선택한다). 결괏값은 반드시 시퀀스에 있는 항목들의 개수보다 작은 음이 아닌 정수가 되어야 하고, 서브스크립션은 인덱스가 그 값이 되는 항목을 선택한다 (0에서 부 터 센다). 음의 인덱스와 슬라이싱에 대한 지원이 객체의 __getitem__() 메서드에서 이루어지기 때문에, 이 메서드를 재정의하는 서브 클래스는 그 지원을 명시적으로 추가할 필요가 있다.

문자열의 항목은 문자다. 문자는 별도의 데이터형이 아니고, 하나의 문자만을 가진 문자열이다.

6.3.3. 슬라이싱(Slicings)¶

슬라이싱은 시퀀스 객체 (예를 들어, 문자열 튜플 리스트)에서 어떤 범위의 항목들을 선택한다. 슬라이싱은 표현식이나 대입의 타깃이나 del 문에 사용될 수 있다. 슬라이싱의 문법은 이렇다:

slicing      ::=  primary "[" slice_list "]"
slice_list   ::=  slice_item ("," slice_item)* [","]
slice_item   ::=  expression | proper_slice
proper_slice ::=  [lower_bound] ":" [upper_bound] [ ":" [stride] ]
lower_bound  ::=  expression
upper_bound  ::=  expression
stride       ::=  expression

이 형식 문법에는 모호함이 있다: 표현식 목록처럼 보이는 것들은 모두 슬라이스 목록으로 보이기도 해서, 모든 서브스크립션이 슬라이싱으로 해석될 수도 있다. 문법을 더 복잡하게 만드는 대신, 이 경우에 서브스크립션으로 해석하는 것이 슬라이싱으로 해석하는 것에 우선한다고 정의하는 것으로 애매함을 제거한다 (이 경우는 슬라이스 목록이 고유한 슬라이스(proper slice) 를 하나도 포함하지 않을 때다).

슬라이싱의 의미는 다음과 같다. 프라이머리가 (일반 서브스크립션과 같은 __getitem__() 메서드를 사용해서) 다음과 같이 슬라이스 목록으로부터 만들어지는 키로 인덱싱된다. 슬라이스 목록이 적어도 하나의 쉼표를 갖는다면, 키는 슬라이스 항목들의 변환을 포함하는 튜플이다; 그렇지 않으면 슬라이스 항목 하나의 변환이 키다. 표현식인 슬라이스 항목의 변환은 그 표현식이다. 고유한 슬라이스(proper slice)의 변환은 슬라이스 객체 (섹션 표준형 계층 를 보라)인데, start, stop, step 어트리뷰트가 각각 lower_bound, upper_bound, stride 로 주어진 표현식이고, 빠진 표현식들을 None 으로 채운다.

6.3.4. 호출¶

호출은 콜러블 객체 (예를 들어, 함수) 를 빌 수도 있는 인자 들의 목록으로 호출한다.

call                 ::=  primary "(" [argument_list [","] | comprehension] ")"
argument_list        ::=  positional_arguments ["," starred_and_keywords]
                            ["," keywords_arguments]
                          | starred_and_keywords ["," keywords_arguments]
                          | keywords_arguments
positional_arguments ::=  ["*"] expression ("," ["*"] expression)*
starred_and_keywords ::=  ("*" expression | keyword_item)
                          ("," "*" expression | "," keyword_item)*
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item | "," "**" expression)*
keyword_item         ::=  identifier "=" expression

생략할 수 있는 마지막 쉼표가 위치나 키워드 인자 뒤에 나타날 수 있지만, 의미를 바꾸지 않는다.

프라이머리의 값을 구하면 콜러블 객체 (사용자 정의 함수, 내장 함수, 내장 객체들의 메서드, 클래스 객체, 클래스 인스턴스의 메서드, __call__() 메서드를 갖는 모든 객체가 콜러블이다) 가 나와야 한다. 모든 인자 표현식들은 호출을 시도하기 전에 값이 구해진다. 형식 파라미터 목록의 문법은 함수 정의 섹션을 참고하면 된다.

키워드 인자가 있으면, 먼저 다음과 같이 위치 인자로 변환된다. 먼저 형식 파라미터들의 채워지지 않은 슬롯들의 목록이 만들어진다. N 개의 위치 인자들이 있다면, 처음 N 개의 슬롯에 넣는다. 그다음, 각 키워드 인자마다, 식별자가 대응하는 슬롯을 결정하는 데 사용된다 (식별자가 첫 번째 형식 파라미터의 이름과 같으면, 첫 번째 슬롯은 사용되고, 이런 식으로 계속한다). 슬롯이 이미 채워졌으면, TypeError 예외를 일으킨다. 그렇지 않으면 그 인자의 값을 슬롯에 채워 넣는다 (표현식이 None 이라 할지라도, 슬롯을 채우게 된다). 모든 인자가 처리되었을 때, 아직 채워지지 않은 슬롯들을 함수 정의로부터 오는 대응하는 기본값들로 채운다. (기본값들은 함수가 정의될 때 한 번만 값을 구한다; 그래서, 리스트나 딕셔너리 같은 가변객체들이 기본값으로 사용되면 해당 슬롯에 인자값을 지정하지 않은 모든 호출에서 공유된다; 보통 이런 상황은 피해야 할 일이다.) 만약 기본값이 지정되지 않고, 아직도 비어있는 슬롯이 남아있다면, TypeError 예외가 발생한다. 그렇지 않으면, 채워진 슬롯의 목록이 호출의 인자 목록으로 사용된다.

CPython implementation detail: 구현은 위치 파라미터가 이름을 갖지 않아서, 설사 문서화의 목적으로 이름이 붙여졌다 하더라도, 키워드로 공급될 수 없는 내장 함수들을 제공할 수 있다. CPython 에서, 인자들을 파싱하기 위해 PyArg_ParseTuple() 를 사용하는 C로 구현된 함수들이 이 경우다.

형식 파라미터 슬롯들보다 많은 위치 인자들이 있으면, *identifier 문법을 사용하는 형식 파라미터가 있지 않은 한, TypeError 예외를 일으킨다; 이 경우, 그 형식 파라미터는 남는 위치 인자들을 포함하는 튜플을 전달받는다 (또는 남는 위치 인자들이 없으면 빈 튜플).

키워드 인자가 형식 파라미터 이름에 대응하지 않으면, **identifier 문법을 사용하는 형식 파라미터가 있지 않은 한, TypeError 예외를 일으킨다; 이 경우, 그 형식 파라미터는 남는 키워드 인자들을 포함하는 딕셔너리나, 남는 위치기반 인자들이 없으면 빈 (새) 딕셔너리를 전달받는다.

문법 *expression 이 함수 호출에 등장하면, expression 의 값은 이터러블 이 되어야 한다. 이 이터러블의 요소들은, 그것들이 추가의 위치 인자들인 것처럼 취급된다. 호출 f(x1, x2, *y, x3, x4) 의 경우, y 의 값을 구할 때 시퀀스 y1, …, yM 이 나온다면, 이것은 M+4개의 위치 인자들 x1, x2, y1, …, yM, x3, x4 로 호출하는 것과 동등하다.

이로 인한 결과는 설사 *expression 문법이 명시적인 키워드 인자 뒤에 나올 수는 있어도, 키워드 인자 (그리고 모든 **expression 인자들 – 아래를 보라) 전에 처리된다는 것이다. 그래서:

>>> def f(a, b):
...     print(a, b)
...
>>> f(b=1, *(2,))
2 1
>>> f(a=1, *(2,))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got multiple values for keyword argument 'a'
>>> f(1, *(2,))
1 2

같은 호출에서 키워드 인자와 *expression 문법을 모두 사용하는 것은 일반적이지 않기 때문에, 실제로는 이런 혼란이 일어나지 않는다.

문법 **expression 이 함수 호출에 등장하면, expression 의 값은 매핑 이 되어야 한다, 그 내용이 추가의 키워드 인자인 것처럼 취급된다. 키워드가 (명시적인 키워드 인자나 다른 언 패킹으로부터) 이미 존재한다면 TypeError 예외가 발생한다.

문법 *identifier 이나 **identifier 를 사용하는 형식 파라미터들은 위치 인자 슬롯이나 키워드 인자 아름들로 사용될 수 없다.

버전 3.5에서 변경: 함수 호출은 임의의 개수의 * and ** 언 패킹을 받아들이고, 위치 인자들이 이터러블 언 패킹 (*) 뒤에 올 수 있고, 키워드 인자가 딕셔너리 언 패킹 (**) 뒤에 올 수 있다. 최초로 PEP 448 에서 제안되었다.

호출은 예외를 일으키지 않는 한, 항상 어떤 값을 돌려준다, None 일 수 있다. 이 값이 어떻게 계산되는지는 콜러블 객체의 형에 달려있다.

만약 그것이—

사용자 정의 함수면:: 인자 목록을 전달해서 함수의 코드 블록이 실행된다. 코드 블록이 처음으로 하는 일은 형식 파라미터들을 인자에 결합하는 것이다; 이것은 섹션 함수 정의 에서 설명한다. 코드 블록이 return 문을 실행하면, 함수 호출의 반환 값을 지정하게 된다.
내장 함수나 메서드면:: 결과는 인터프리터에 달려있다; 내장 함수와 메서드들에 대한 설명은 내장 함수 를 보면 된다.
클래스 객체면:: 그 클래스의 새 인스턴스가 반환된다.
클래스 인스턴스 메서드면:: 대응하는 사용자 정의 함수가 호출되는데, 그 인스턴스가 첫 번째 인자가 되는 하나만큼 더 긴 인자 목록이 전달된다.
클래스 인스턴스면:: 그 클래스는 __call__() 메서드를 정의해야 한다; 그 효과는 그 메서드가 호출되는 것과 같다.

6.4. 어웨이트 표현식¶

어웨이터블 에서 코루틴 의 실행을 일시 중지한다. 오직 코루틴 함수 에서만 사용할 수 있다.

await_expr ::=  "await" primary

버전 3.5에 추가.

6.5. 거듭제곱 연산자¶

거듭제곱 연산자는 그것의 왼쪽에 붙는 일 항 연산자보다 더 강하게 결합한다; 그것의 오른쪽에 붙는 일 항 연산자보다는 약하게 결합한다. 문법은 이렇다:

power ::=  (await_expr | primary) ["**" u_expr]

그래서, 괄호가 없는 거듭제곱과 일 항 연산자의 시퀀스에서, 연산자는 오른쪽에서 왼쪽으로 값이 구해진다 (이것이 피연산자의 값을 구하는 순서를 제약하는 것은 아니다): -1**2 은 -1 이 된다.

거듭제곱 연산자는 내장 pow() 함수가 두 개의 인자로 호출될 때와 같은 의미가 있다: 왼쪽 인자를 오른쪽 인자만큼 거듭제곱한 값을 준다. 숫자 인자는 먼저 공통 형으로 변환되고, 결과는 그 형이다.

int 피연산자의 경우, 두 번째 인자가 음수가 아닌 이상 결과는 피연산자들과 같은 형을 갖는다; 두 번째 인자가 음수면, 모든 인자는 float로 변환되고, float 결과가 전달된다. 예를 들어, 10**2 는 100 를 돌려주지만, 10**-2 는 0.01 를 돌려준다.

0.0 를 음수로 거듭제곱하면 ZeroDivisionError 를 일으킨다. 음수를 분수로 거듭제곱하면 복소수(complex)가 나온다. (예전 버전에서는 ValueError 를 일으켰다.)

6.6. 일 항 산술과 비트 연산¶

모든 일 항 산술과 비트 연산자는 같은 우선순위를 갖는다.

u_expr ::=  power | "-" u_expr | "+" u_expr | "~" u_expr

일 항 - (마이너스) 연산자는 그 숫자 인자의 음의 값을 준다.

일 항 + (플러스) 연산자는 그 숫자 인자의 값을 변경 없이 준다.

일 항 ~ (인버트) 연산자는 그 정수 인자의 비트 반전된 값을 준다. x 의 비트 반전은 -(x+1) 로 정의된다. 오직 정수에만 적용된다.

세 가지 경우 모두, 인자가 올바른 형을 갖지 않는다면, TypeError 예외가 발생한다.

6.7. 이항 산술 연산¶

이항 산술 연산자는 관습적인 우선순위를 갖는다. 이 연산자 중 일부는 일부 비 숫자 형에도 적용됨에 주의해야 한다. 거듭제곱 연산자와는 별개로, 오직 두 가지 수준만 있는데, 하나는 곱셈형 연산자들이고, 하나는 덧셈형 연산자들이다.

m_expr ::=  u_expr | m_expr "*" u_expr | m_expr "@" m_expr |
            m_expr "//" u_expr | m_expr "/" u_expr |
            m_expr "%" u_expr
a_expr ::=  m_expr | a_expr "+" m_expr | a_expr "-" m_expr

* (곱셈) 연산자는 인자들의 곱을 준다. 인자들은 모두 숫자거나, 한 인자는 정수고 다른 인자는 시퀀스여야 한다. 앞의 경우에, 숫자들은 공통 형으로 변환된 후 곱해진다. 후자의 경우, 시퀀스의 반복이 수행된다; 음의 반복 값은 빈 시퀀스를 만든다.

@ (at) 연산자는 행렬 곱셈에 사용하려는 것이다. 파이썬의 내장형들 어느 것도 이 연산자를 구현하지 않는다.

버전 3.5에 추가.

/ (나눗셈)과 // (정수 나눗셈, floor division) 연산자들은 그 인자들의 몫(quotient)을 준다. 숫자 인자들은 먼저 공통형으로 변환된다. 정수들의 나눗셈은 실수를 만드는 반면, 정수들의 정수 나눗셈은 정숫값을 준다; 그 결과는 수학적인 나눗셈의 결과에 〈floor〉 함수를 적용한 것이다. 0으로 나누는 것은 ZeroDivisionError 예외를 일으킨다.

% (모듈로, modulo) 연산자는 첫 번째 인자를 두 번째 인자로 나눈 나머지를 준다. 숫자 인자들은 먼저 공통형으로 변환된다. 오른쪽 인자가 0이면 ZeroDivisionError 예외를 일으킨다. 인자들은 실수가 될 수 있다, 예를 들어, 3.14%0.7 는 0.34 와 같다 (3.14 가 4*0.7 + 0.34 와 같으므로.) 모듈로 연산자는 항상 두 번째 피연산자와 같은 부호를 갖는 결과를 준다 (또는 0이다); 결과의 절댓값은 두 번째 피연산자의 절댓값보다 작다 1.

정수 나눗셈과 모듈로 연산자는 다음과 같은 항등식으로 연결되어 있다: x == (x//y)*y + (x%y). 정수 나눗셈과 모듈로는 내장 함수 divmod() 와도 연결되어 있다: divmod(x, y) == (x//y, x%y). 2.

숫자들에 대해 모듈로 연산을 수행하는 것에 더해, % 연산자는 예전 스타일의 문자열 포매팅 (인터폴레이션이라고도 알려져 있다)을 수행하기 위해 문자열 객체에 의해 다시 정의된다. 문자열 포매팅의 문법은 파이썬 라이브러리 레퍼런스의 섹션 printf 스타일 문자열 포매팅 에서 설명한다.

정수 나눗셈 연산자, 모듈로 연산자, divmod() 함수는 복소수에 대해서는 정의되어 있지 않다. 대신, 적절하다면, abs() 함수를 사용해서 실수로 변환하라.

+ (덧셈) 연산자는 그 인자들의 합을 준다. 인자들은 둘 다 숫자거나, 둘 다 같은 형의 시퀀스여야 한다. 앞의 경우, 숫자들은 먼저 공통형으로 변환된 후, 함께 합쳐진다. 후자의 경우 시퀀스는 이어붙이게 된다.

- (빼기) 연산자는 그 인자들의 차를 준다. 숫자 인자들은 먼저 공통형으로 변환된다.

6.8. 시프트 연산¶

시프트 연산은 산술 연산보다 낮은 우선순위를 갖는다.

shift_expr ::=  a_expr | shift_expr ("<<" | ">>") a_expr

이 연산들은 정수들을 인자로 받아들인다. 첫 번째 인자를 두 번째 인자로 주어진 비트 수만큼 왼쪽이나 오른쪽으로 민(shift)다.

오른쪽으로 n 비트 시프트 하는 것은 pow(2,n) 로 정수 나눗셈하는 것으로 정의된다. 왼쪽으로 n 비트 시프트 하는 것은 pow(2,n) 를 곱하는 것으로 정의된다.

참고

현재 구현에서, 우측 피연산자는 최대 sys.maxsize 일 것이 요구된다. 우측 피연산자가 sys.maxsize 보다 크면 OverflowError 예외가 발생한다.

6.9. 이항 비트 연산¶

세 개의 비트 연산은 각기 다른 우선순위를 갖는다:

and_expr ::=  shift_expr | and_expr "&" shift_expr
xor_expr ::=  and_expr | xor_expr "^" and_expr
or_expr  ::=  xor_expr | or_expr "|" xor_expr

& 연산자는 그 인자들의 비트별 AND를 주는데, 인자들은 정수여야 한다.

^ 연산자는 그 인자들의 비트별 XOR (배타적 OR)를 주는데, 인자들은 정수여야 한다.

| 연산자는 그 인자들의 비트별 (포함적, inclusive) OR를 주는데, 인자들은 정수여야 한다.

6.10. 비교¶

C와는 달리, 파이썬에서 모든 비교 연산은 같은 우선순위를 갖는데, 산술, 시프팅, 비트 연산들보다 낮다. 또한, C와는 달리, a < b < c 와 같은 표현식이 수학에서와 같은 방식으로 해석된다.

comparison    ::=  or_expr (comp_operator or_expr)*
comp_operator ::=  "<" | ">" | "==" | ">=" | "<=" | "!="
                   | "is" ["not"] | ["not"] "in"

비교는 논리값을 준다: True 또는 False

비교는 자유롭게 연결될 수 있다, 예를 들어, x < y <= z 는 x < y and y <= z 와 동등한데, 차이점은 y 의 값을 오직 한 번만 구한다는 것이다 (하지만 두 경우 모두 x < y 가 거짓이면 z 의 값은 구하지 않는다).

형식적으로, a, b, c, …, y, z 가 표현식이고, op1, op2, …, opN 가 비교 연산자면, a op1 b op2 c ... y opN z 는 각 표현식의 값을 최대 한 번만 구한다는 점을 제외하고는 a op1 b and b op2 c and ... y opN z 와 동등하다.

a op1 b op2 c 가 a 와 c 간의 어떤 종류의 비교도 암시하지 않기 때문에, 예를 들어, x < y > z 이 완벽하게 (아마 이쁘지는 않더라도) 올바르다는 것에 주의해야 한다.

6.10.1. 값 비교¶

연산자 <, >, ==, >=, <=, != 는 두 객체의 값을 비교한다. 객체들이 같은 형일 필요는 없다.

객체, 값, 형 장은 객체들이 (형과 아이덴티티에 더해) 값을 갖는다고 말하고 있다. 파이썬에서 객체의 값은 좀 추상적인 개념이다: 예를 들어, 객체의 값에 대한 규범적인(canonical) 액세스 방법은 없다. 또한, 객체의 값이 특별한 방식(예를 들어, 모든 데이터 어트리뷰트로 구성되는 것)으로 구성되어야 한다는 요구 사항도 없다. 비교 연산자는 객체의 값이 무엇인지에 대한 특정한 종류의 개념을 구현한다. 객체의 값을 비교를 통해 간접적으로 정의한다고 생각해도 좋다.

모든 형은 (직접적 혹은 간접적으로) object 의 서브 형이기 때문에, 그들은 object 로 부터 기본 비교 동작을 계승한다. 형들은 __lt__() 와 같은 풍부한 비교 메서드(rich comparison methods) 를 구현해서 자신의 비교 동작을 커스터마이즈할 수 있는데, 기본적인 커스터마이제이션 에서 설명된다.

동등 비교 (== 와 !=) 의 기본 동작은 객체의 아이덴티티에 기반을 둔다. 그래서, 같은 아이덴티티를 갖는 인스턴스 간의 동등 비교는 같음을 주고, 다른 아이덴티티를 갖는 인스턴스 간의 동등 비교는 다름을 준다. 이 기본 동작의 동기는 모든 객체가 반사적(reflexive) (즉, x is y 는 x == y 를 암시한다) 이도록 만들고자 하는 욕구다.

기본 대소 비교(order comparison) (<, >, <=, >=) 는 제공되지 않는다; 시도하면 TypeError 를 일으킨다. 이 기본 동작의 동기는 동등함과 유사한 항등 관계가 없다는 것이다.

다른 아이덴티티를 갖는 인스턴스들이 항상 서로 다르다는, 기본 동등 비교의 동작은, 객체의 값과 값 기반의 동등함에 대한 나름의 정의를 가진 형들이 필요로 하는 것과는 크게 다를 수 있다. 그런 형들은 자신의 비교 동작을 커스터마이즈 할 필요가 있고, 사실 많은 내장형이 그렇게 하고 있다.

다음 목록은 가장 중요한 내장형들의 비교 동작을 기술한다.

내장 숫자 형 ((숫자 형 — int, float, complex)) 과 표준 라이브러리 형 fractions.Fraction 과 decimal.Decimal 에 속하는 숫자들은, 복소수가 대소 비교를 지원하지 않는다는 제약 사항만 빼고는, 같거나 다른 형들 간의 비교가 가능하다. 관련된 형들의 한계 안에서, 정밀도의 손실 없이 수학적으로 (알고리즘 적으로) 올바르게 비교한다.

NaN(not-a-number) 값들 float('NaN') 과 Decimal('NaN') 은 특별하다. 이것들은 자기 자신과 같은 객체지만 (x is x 는 참이다), 자기 자신과 같지는 않다 (x == x 는 거짓이다.). 추가로, 어떤 숫자건 NaN 값과 비교하면 False 를 돌려준다. 예를 들어, 3 < float('NaN') 과 float('NaN') < 3 모두 False 를 돌려준다.
바이너리 시퀀스들 (bytes 나 bytearray 의 인스턴스들)은 형을 건너 상호 비교될 수 있다. 이것들은 요소들의 숫자 값을 사용해서 사전식으로(lexicographically) 비교한다.
문자열들 (str 의 인스턴스들) 은 문자들의 유니코드 코드 포인트(Unicode code points) (내장 함수 ord() 의 결과)를 사용해서 사전식으로 비교한다. 3

문자열과 바이너리 시퀀스는 직접 비교할 수 없다.
시퀀스들 (tuple, list, range 의 인스턴스들)은 같은 형끼리 비교될 수 있는데, range는 대소 비교를 지원하지 않는다. 서로 다른 형들 간의 동등 비교는 다름을 주고, 서로 다른 형들 간의 대소 비교는 TypeError 를 일으킨다.

시퀀스는 대응하는 요소 간의 비교를 사용해서 사전적으로 비교하는데, 요소들의 반사성(reflexivity)이 강제된다.

요소들의 반사성을 강제한다는 것은, 컬렉션의 비교가 컬렉션 요소 x 에 대해, x == x 가 항상 참이라고 가정한다는 것이다. 그 가정에 기반을 둬서, 요소들의 아이덴티티가 먼저 비교된 후에, 이것이 다를 때만 요소 간의 동등 비교가 수행된다. 비교되는 요소들이 반사적일 때, 이런 접근법은 엄밀한 요소 간 비교와 같은 결과를 준다. 비 반사적인 요소의 경우, 결과가 엄밀한 요소 비교와 달라질 수 있고, 놀랄 수 있다: 예를 들어, 비 반사적인 NaN이 리스트에서 사용될 때 다음과 같은 비교 동작을 보인다:
```
>>> nan = float('NaN')
>>> nan is nan
True
>>> nan == nan
False                 <-- the defined non-reflexive behavior of NaN
>>> [nan] == [nan]
True                  <-- list enforces reflexivity and tests identity first
```
내장 컬렉션들의 사전적인 비교는 다음과 같이 이루어진다:
- 두 컬렉션이 같다고 비교되기 위해서는, 같은 형이고, 길이가 같고, 대응하는 요소들의 각 쌍이 같다고 비교되어야 한다 (예를 들어, [1,2] == (1,2) 는 거짓인데, 형이 다르기 때문이다).
- 대소 비교를 지원하는 컬렉션들은 첫 번째로 다른 요소들과 같은 순서를 준다 (예를 들어, [1,2,x] <= [1,2,y] 는 x <= y 와 같은 값이다). 대응하는 요소가 없는 경우 더 짧은 컬렉션이 작다고 비교된다 (예를 들어, [1,2] < [1,2,3] 은 참이다).
매핑들 (dict 의 인스턴스들) 은 같은 (key, value) 쌍들을 가질 때, 그리고 오직 이 경우만 같다고 비교된다. 키와 값의 동등 비교는 반사성을 강제한다.

대소 비교 (<, >, <=, >=) 는 TypeError 를 일으킨다.
집합들 (set 이나 frozenset 의 인스턴스들)은 같은 형들과 서로 다른 형들 간에 비교될 수 있다.

이것들은 부분집합(subset)과 상위집합(superset)을 뜻하는 대소비교 연산자들을 정의한다. 이 관계는 전 순서(total ordering)를 정의하지 않는다 (예를 들어, 두 집합 {1,2} 와 {2,3} 는 다르면서도, 하나가 다른 하나의 부분집합이지도, 하나가 다른 하나의 상위집합이지도 않다). 따라서, 전 순서에 의존하는 함수의 인자로는 적합하지 않다 (예를 들어, min(), max(), sorted() 에 입력으로 집합의 리스트를 제공하면 정의되지 않은 결과를 준다).

집합의 비교는 그 요소들의 반사성을 강제한다.
대부분의 다른 내장형들은 비교 메서드들을 구현하지 않기 때문에, 기본 비교 동작을 계승한다.

비교 동작을 커스터마이즈하는 사용자 정의 클래스들은 가능하다면 몇 가지 일관성 규칙을 준수해야 한다:

동등 비교는 반사적(reflexive)이어야 한다. 다른 말로 표현하면, 아이덴티티가 같은 객체는 같다고 비교되어야 한다:

x is y 면 x == y 다.
비교는 대칭적(symmetric)이어야 한다. 다른 말로 표현하면, 다음과 같은 표현식은 같은 결과를 주어야 한다:

x == y 와 y == x

x != y 와 y != x

x < y 와 y > x

x <= y 와 y >= x
비교는 추이적(transitive)이어야 한다. 다음 (철저하지 않은) 예들이 이것을 예증한다:

x > y and y > z 면 x > z 다

x < y and y <= z`` 면 x < z 다
역 비교는 논리적 부정이 되어야 한다. 다른 말로 표현하면, 다음 표현식들이 같은 값을 주어야 한다:

x == y 와 not x != y

x < y 와 not x >= y (전 순서의 경우)

x > y 와 not x <= y (전 순서의 경우)

마지막 두 표현식은 전 순서 컬렉션에 적용된다 (예를 들어, 시퀀스에는 적용되지만, 집합과 매핑은 그렇지 않다). total_ordering() 데코레이터 또한 보기 바란다.
hash() 결과는 동등성과 일관성을 유지해야 한다. 같은 객체들은 같은 해시값을 같거나 해시 불가능으로 지정되어야 한다.

파이썬은 이 일관성 규칙들을 강제하지 않는다. 사실 NaN 값들은 이 규칙을 따르지 않는 예다.

6.10.2. 멤버십 검사 연산¶

연산자 in 과 not in 은 멤버십을 검사한다. x in s 는 x 가 s 의 멤버일 때 True 를, 그렇지 않을 때 False 를 준다. x not in s 은 x in s 의 부정을 준다. 딕셔너리 뿐만 아니라 모든 내장 시퀀스들과 집합 형들이 이것을 지원하는데, 딕셔너리의 경우는 in 이 딕셔너리에 주어진 키가 있는지 검사한다. list, tuple, set, frozenset, dict, collections.deque 와 같은 컨테이너형들의 경우, 표현식 x in y 는 any(x is e or x == e for e in y) 와 동등하다.

문자열과 바이트열 형의 경우, x in y 는 x 가 y 의 서브 스트링(substring)인 경우, 그리고 오직 그 경우만 True 다. 동등한 검사는 y.find(x) != -1 다. 빈 문자열은 항상 다른 문자열들의 서브 스트링으로 취급되기 때문에, "" in "abc" 은 True 를 돌려준다.

__contains__() 메서드를 정의하는 사용자 정의 클래스의 경우, x in y 는 y.__contains__(x) 가 참을 줄 때 True 를, 그렇지 않으면 False 를 돌려준다.

__contains__() 를 정의하지 않지만 __iter__() 를 정의하는 사용자 정의 클래스의 경우, x in y 는 y 를 탐색할 때 x == z 를 만족하는 어떤 값 z 가 만들어지면 True 다. 탐색하는 동안 예외가 발생하면 in 이 그 예외를 일으킨 것으로 취급된다.

마지막으로, 올드스타일(old-style) 이터레이션 프로토콜을 시도한다: 클래스가 __getitem__() 를 정의하면, x in y 는 x == y[i] 를 만족하는 음이 아닌 정수 인덱스 i 가 존재하고, 그보다 작은 모든 정수 인덱스들에 대해 IndexError 예외를 일으키지 않는 경우, 그리고 오직 그 경우만 True 가 된다. (그 밖의 예외가 발생하면 in 이 그 예외를 일으킨 것으로 취급된다.

연산자 not in 은 in 의 논리적 부정으로 정의된다.

6.10.3. 아이덴티티 비교¶

연산자 is 와 is not 은 객체의 아이덴티티를 검사한다: x is y 는 x 와 y 가 아이덴티티가 같은 객체일 때, 그리고 오직 그 경우만 참이다. 객체의 아이덴티티는 id() 함수를 사용해서 결정된다. x is not y 은 논리적 부정 값을 준다. 4

6.11. 논리 연산(Boolean operations)¶

or_test  ::=  and_test | or_test "or" and_test
and_test ::=  not_test | and_test "and" not_test
not_test ::=  comparison | "not" not_test

논리 연산의 문맥에서, 그리고 표현식이 제어 흐름 문(control flow statements)에서 사용될 때, 다음 값들은 거짓으로 해석된다: False, None, 모든 형의 숫자 0, 빈 문자열과 컨테이너(문자열, 튜플, 리스트, 딕셔너리, 집합, 불변 집합(frozenset)들을 포함한다). 그 밖의 모든 값은 참으로 해석된다. 사용자 정의 객체들은 __bool__() 메서드를 제공해서 자신의 논리값(truth value)을 커스터마이즈 할 수 있다.

연산자 not 은 그 인자가 거짓이면 True 를, 그렇지 않으면 False 를 준다.

표현식 x and y 는 먼저 x 의 값을 구한다; x 가 거짓이면 그 값을 돌려준다; 그렇지 않으면 y 의 값을 구한 후에 그 결과를 돌려준다.

표현식 x or y 는 먼저 x 의 값을 구한다; x 가 참이면 그 값을 돌려준다. 그렇지 않으면 y 의 값을 구한 후에 그 결과를 돌려준다.

Note that neither and nor or restrict the value and type they return to False and True, but rather return the last evaluated argument. This is sometimes useful, e.g., if s is a string that should be replaced by a default value if it is empty, the expression s or 'foo' yields the desired value. Because not has to create a new value, it returns a boolean value regardless of the type of its argument (for example, not 'foo' produces False rather than ''.)

6.12. 조건 표현식(Conditional expressions)¶

conditional_expression ::=  or_test ["if" or_test "else" expression]
expression             ::=  conditional_expression | lambda_expr
expression_nocond      ::=  or_test | lambda_expr_nocond

조건 표현식은 (때로 《삼 항 연산자(ternary operator)》라고 불린다) 모든 파이썬 연산에서 가장 낮은 우선순위를 갖는다.

표현식 x if C else y 은 먼저 x 대신에 조건 C 의 값을 구한다. C 가 참이면, x 의 값이 구해지고 그 값을 돌려준다; 그렇지 않으면, y 의 값을 구한 후에 그 결과를 돌려준다.

조건 표현식에 대한 더 자세한 내용은 PEP 308 를 참고하라.

6.13. 람다(Lambdas)¶

lambda_expr        ::=  "lambda" [parameter_list] ":" expression
lambda_expr_nocond ::=  "lambda" [parameter_list] ":" expression_nocond

람다 표현식은 (때로 람다 형식(lambda forms)이라고 불린다) 이름 없는 함수를 만드는 데 사용된다. 표현식 lambda parameters: expression 는 함수 객체를 준다. 이 이름 없는 객체는 이렇게 정의된 함수 객체처럼 동작한다:

def <lambda>(parameters):
    return expression

파라미터 목록의 문법은 함수 정의 섹션을 보면 된다. 람다 표현식으로 만들어진 함수는 문장(statements)이나 어노테이션(annotations)을 포함할 수 없음에 주의해야 한다.

6.14. 표현식 목록(Expression lists)¶

expression_list    ::=  expression ("," expression)* [","]
starred_list       ::=  starred_item ("," starred_item)* [","]
starred_expression ::=  expression | (starred_item ",")* [starred_item]
starred_item       ::=  expression | "*" or_expr

리스트나 집합 디스플레이의 일부일 때를 제외하고, 최소한 하나의 쉼표를 포함하는 표현식 목록은 튜플을 준다. 튜플의 길이는 목록에 있는 표현식의 개수다. 표현식들은 왼쪽에서 오른쪽으로 값이 구해진다.

애스터리스크(asterisk) * 는 이터러블 언 패킹(iterable unpacking)을 나타낸다. 피연산자는 반드시 이터러블 이어야 한다. 그 이터러블이 항목들의 시퀀스로 확장되어서, 언 패킹 지점에서 새 튜플, 리스트, 집합에 포함된다.

버전 3.5에 추가: 표현식 목록에서의 이터러블 언 패킹, PEP 448 에서 최초로 제안되었다.

끝에 붙는 쉼표는 단일 튜플(single tuple) (소위, 싱글톤(singleton)) 을 만들 때만 필수다; 다른 모든 경우에는 생략할 수 있다. 끝에 붙는 쉼표가 없는 단일 표현식은 튜플을 만들지 않고, 그 표현식의 값을 준다. (빈 튜플을 만들려면, 빈 괄호 쌍을 사용하라: ().)

6.15. 값을 구하는 순서¶

파이썬은 왼쪽에서 오른쪽으로 표현식의 값을 구한다. 대입의 값을 구하는 동안, 우변의 값이 좌변보다 먼저 구해짐에 주목하라.

다 줄들에서, 표현식은 그들의 끝에 붙은 숫자들의 순서대로 값이 구해진다:

expr1, expr2, expr3, expr4
(expr1, expr2, expr3, expr4)
{expr1: expr2, expr3: expr4}
expr1 + expr2 * (expr3 - expr4)
expr1(expr2, expr3, *expr4, **expr5)
expr3, expr4 = expr1, expr2

6.16. 연산자 우선순위¶

다음 표는 파이썬 에서의 연산자 우선순위를 가장 낮은 것 (least binding)에서 가장 높은 것 (most binding) 순으로 요약한다. 같은 상자에 들어있는 연산자들은 같은 우선순위를 갖는다. 문법이 명시적으로 주어지지 않는 이상, 연산자들은 이항(binary)이다. 같은 상자에 있는 연산자들은 왼쪽에서 오른쪽으로 그룹 지어진다 (거듭제곱은 예외인데, 오른쪽에서 왼쪽으로 그룹 지어진다).

비교, 멤버십 검사, 아이덴티티 검사들은 모두 같은 우선순위를 갖고 비교 섹션에서 설명한 것처럼 왼쪽에서 오른쪽으로 이어붙이기(chaining) 하는 기능을 갖는다.

연산자	설명
`lambda`	람다 표현식
`if` – `else`	조건 표현식
`or`	논리 OR
`and`	논리 AND
`not` `x`	논리 NOT
`in`, `not in`, `is`, `is not`, `<`, `<=`, `>`, `>=`, `!=`, `==`	비교, 멤버십 검사와 아이덴티티 검사를 포함한다
`\|`	비트 OR
`^`	비트 XOR
`&`	비트 AND
`<<`, `>>`	시프트
`+`, `-`	덧셈과 뺄셈
`*`, `@`, `/`, `//`, `%`	곱셈, 행렬 곱셈, 나눗셈, 정수 나눗셈, 나머지 5
`+x`, `-x`, `~x`	양, 음, 비트 NOT
`**`	거듭제곱 6
`await` `x`	어웨이트 표현식
`x[index]`, `x[index:index]`, `x(arguments...)`, `x.attribute`	서브스크립션, 슬라이싱, 호출, 어트리뷰트 참조
`(expressions...)`, `[expressions...]`, `{key: value...}`, `{expressions...}`	결합(binding) 또는 튜플 디스플레이, 리스트 디스플레이, 딕셔너리 디스플레이, 집합 디스플레이

각주

1

abs(x%y) < abs(y) 이 수학적으로는 참이지만, float의 경우에는 소수점 자름(roundoff) 때문에 수치적으로 참이 아닐 수 있다. 예를 들어, 파이썬 float가 IEEE 754 배정도 숫자인 플랫폼을 가정할 때, -1e-100 % 1e100 가 1e100 와 같은 부호를 가지기 위해, 계산된 결과는 -1e-100 + 1e100 인데, 수치적으로는 1e100 과 정확히 같은 값이다. 함수 math.fmod() 는 부호가 첫 번째 인자의 부호에 맞춰진 결과를 주기 때문에, 이 경우 -1e-100 을 돌려준다. 어떤 접근법이 더 적절한지는 응용 프로그램에 달려있다.

2

x가 y의 정확한 정수배와 아주 가까우면, 라운딩(rounding) 때문에 x//y 는 (x-x%y)//y 보다 1 클 수 있다. 그런 경우, divmod(x,y)[0] * y + x % y 가 x 와 아주 가깝도록 유지하기 위해, 파이썬은 뒤의 결과를 돌려준다.

3

유니코드 표준은 코드 포인트(code points) (예를 들어, U+0041) 와 추상 문자(abstract characters) (예를 들어, 《LATIN CAPITAL LETTER A》) 를 구분한다. 유니코드에 있는 대부분의 추상 문자들이 오직 하나의 코드 포인트만으로 표현되지만, 추가로 하나 이상의 코드 포인트의 시퀀스로 표현될 수 있는 추상 문자들이 많이 있다. 예를 들어, 추상 문자 《LATIN CAPITAL LETTER C WITH CEDILLA》 는 코드 위치 U+00C7 에 있는 한 개의 복합 문자(precomposed character) 나 코드 위치 U+0043 (LATIN CAPITAL LETTER C) 에 있는 기본 문자(base character) 와 뒤따르는 코드 위치 U+0327 (COMBINING CEDILLA) 에 있는 결합 문자(combining character) 의 시퀀스로 표현될 수 있다.

문자열의 비교 연산자는 유니코드 코드 포인트 수준에서 비교한다. 이것은 사람에게 반 직관적일 수 있다. 예를 들어, "\u00C7" == "\u0043\u0327" 는 거짓이다, 설사 두 문자열이 같은 추상 문자 《LATIN CAPITAL LETTER C WITH CEDILLA》를 표현할지라도 그렇다.

문자열을 추상 문자 수준에서 비교하려면 (즉, 사람에게 직관적인 방법으로), unicodedata.normalize() 를 사용하라.

4

자동 가비지-수거(automatic garbage-collection)와 자유 목록(free lists)과 디스크립터(descriptor)의 동적인 성격 때문에, is 연산자를 인스턴스 메서드들이나 상수들을 비교하는 것과 같은 특정한 방식으로 사용할 때, 겉으로 보기에 이상한 동작을 감지할 수 있다. 더 자세한 정보는 그들의 문서를 확인하기 바란다.

5

% 연산자는 문자열 포매팅에도 사용된다; 같은 우선순위가 적용된다.

6

거듭제곱 연산자 ** 는 오른쪽에 오는 산술이나 비트 일 항 연산자보다 약하게 결합한다, 즉, 2**-1 는 0.5 다.