파이썬 제너레이터
지난 글에서는, 생산자-소비자 패턴(Producer-Consumer Pattern)의 소비자 쪽의 코드를, 함축적이면서도 자연스럽게 기술할 수 있는 방법을 제공하는 이터레이터를 살펴봤습니다. 오늘은 생산자 쪽을 들여다봅니다.
앞서 Range 라는 클래스를 통해 이터레이터를 살펴보았습니다만, 이 코드에는 불편한 부분이 있습니다. 대부분의 작업은 __next__() 메쏘드를 통해 구현되는데, 매번 예전의 상태를 복구한 후, 작업을 수행하고, 다시 상태를 저장하는 작업을 반복하게 됩니다. Range 와 같은 간단한 작업에서야 문제될 것이 없지만, 알고리즘을 기술하는 자연스러운 방식에서 벗어나 있기 때문에, 작업이 복잡해질수록 점점 문제가 됩니다. 이런 스타일의 프로그래밍은 이벤트 주도형 프로그래밍(event-driven programming)에서 자주 등장하는데, 비동기 IO(Asynchronous IO) 나 GUI 프로그래밍을 해 보셨다면 이미 익숙할 겁니다.(지금 우리가 걷고 있는 길은 이 문제들에 대한 직접적인 해결책으로 이어집니다. 하지만 아직은 갈 길이 멉니다.)
파이썬에서는 제너레이터(generator)라는 이터레이터의 확장을 제공합니다. 이터레이터가 단지 프로토콜인데 반해, 제너레이터는 yield 라는 전용의 키워드를 통해 문법적인 특별함을 더합니다. Range 를 제너레이터로 다시 구현해 보겠습니다. (되도록 이터레이터 구현과 유사하게 코드를 구성했습니다.)
>>> def Range(n):
... c = 0
... while c < n:
... yield c
... c += 1
>>> for x in Range(3):
... print(x)
0
1
2
파이썬은 함수 정의에 yield 키워드가 등장하면 그 함수 전체를 제너레이터로 인식하고, 특별한 VM 코드를 생성해냅니다. 함수의 코드를 재구성해서 같은 일을 하는 이터레이터를 만든 다음, 원래 함수는 그 이터레이터 인스턴스를 돌려주는 함수로 바꾼다고 보시면 됩니다.
>>> Range(3)
<generator object Range at 0x1017d3370>
제너레이터는 이터레이터입니다.
>>> r = Range(3)
>>> next(r)
0
>>> next(r)
1
>>> next(r)
2
>>> next(r)
Traceback (most recent call last):
File "<console>", line 1, in <module>
StopIteration
이터레이터 구현과 제너레이터 구현간에는 이런 문법적인 차이가 있습니다.
- 이터레이터 구현에서 __next__() 의 return 값은, 제너레이터 구현에서는 yield 값으로 대체됩니다.
- 제너레이터에서 return 문은 StopIteration 예외를 일으킵니다. 함수의 끝에 도달해도 마찬가지 입니다. 파이썬 3 에서는 return 문이 값을 포함할 수도 있지만, 오늘 다룰 범위를 벗어납니다.
제너레이터를 위해 파이썬이 만들어내는 이터레이터를 제너레이터-이터레이터(generator-iterator)라고 부르는데, 이터레이터는 프로토콜인 반면 제너레이터-이터레이터는 실제 구현이 제공되는 것이라, 일반적인 이터레이터에서 지정하지 않은 동작들이 구체적으로 정의되기도 합니다.
가령 예외의 경우, 이터레이터의 __next__() 가 StopIteration 또는 그 외의 예외를 일으킨 후에 이터레이터가 어떤 상태가 되는지는 정의되어있지 않습니다. 하지만 제너레이터의 경우는 항상 이렇게 됩니다.
- 일단 StopIteration 예외가 일어나면 그 이후에는 계속 StopIteration 예외를 일으킵니다.
- StopIteration 이외의 예외가 일어나면, 일단 caller 에게 예외가 전달됩니다. 하지만 그 이후로는 계속 StopIteration 예외를 일으킵니다.
재진입(Reentrancy) 문제도 이터레이터에서는 정의되어있지 않습니다. 가령 __next__() 메쏘드 내에서 직접적이던 간접적이던 next(self) 를 호출했을 때 어떤 일이 일어나야 할지 지정되어 있지 않다는 것입니다. 그러니 재귀적인 구현도 생각해볼 수 있습니다. 하지만 제너레이터에서는 재진입이 허락되지 않습니다.
>>> this = (lambda: (yield next(this)))()
>>> next(this)
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "<console>", line 1, in <lambda>
ValueError: generator already executing
그런데 이 예에서 볼 수 있듯이 lambda 로 제너레이터를 만들어도 문제가 되지는 않습니다. 그런데 lambda 의 바디에는 문장(statement)이 아니라 표현식(expression) 이 온다는 것을 기억하십니까? yield 를 둘러싼 괄호가 yield 가 표현식임을 알려줍니다. 예 지금까지 저희는 yield 를 문장처럼 사용해 왔습니다만, 사실 yield 는 표현식입니다. 그러면 그 값은 뭘까요?
지금까지의 예 에서 yield 표현식(yield expression)의 값은 None 입니다.
>>> def G():
while True:
input = yield 'output'
print(repr(input))
>>> g = G()
>>> next(g)
'output'
>>> next(g)
None
'output'
처음 인쇄된 'output' 은 next(g) 의 반환 값이고, 다음 next(g) 호출의 처음에 인쇄된 None 이 yield 표현식의 결과값입니다. 순서를 잘 기억하세요, 첫 번째 next() 에서 yield 로 값을 전달한 후에, 다음 next() 가 호출될 때야 비로소 yield 표현식이 값을 전달합니다.
caller 가 제너레이터로 값을 전달해 준다면 yield 표현식은 None 이외의 값을 가질 수 있습니다. 이를 위해 제너레이터에는 send() 라는 메쏘드가 제공됩니다.
>>> g = G()
>>> next(g)
'output'
>>> g.send('input')
'input'
'output'
None 이 send() 가 전달한 'input'으로 대체된 것을 확인하실 수 있습니다. 주의할 부분은 첫 번째 next(g) 대신 g.send('input') 을 사용할 수 없다는 것입니다.
>>> g = G()
>>> g.send('input')
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: can't send non-None value to a just-started generator
이유는 앞에서 주의를 부탁한 실행 순서 때문입니다. 첫 번째 yield 표현식은 최초의 yield 가 일어난 후에 전달됩니다. 즉 send() 메쏘드는 yield 로 값을 전달한 후에, caller 가 next() 나 send() 를 호출해주기를 기다리고 있는 제너레이터에만 사용될 수 있습니다. 꼭 send() 를 사용해야 한다면 None 을 전달할 수 있습니다.
>>> g = G()
>>> g.send(None)
'output'
next(g) 는 g.send(None) 과 같은 의미로 해석됩니다.
제너레이터에는 send() 외에도 throw() 와 close() 라는 메쏘드가 더 제공됩니다. 이 메쏘드들은 나중에 다룰 기회가 있을 겁니다만, 제너레이터에 이런 기능들이 들어간 목적이 무엇일까요? 그 것은 바로 다음에 다룰 코루틴(coroutine) 때문입니다.