IT/모바일
저자: 스티브 피긴스(Stephen Figgins), 역 전순재
고든 맥밀란(Gordon McMillan)은 파이썬 인터프리터의 코어를 스택리스로 만들기 위한 파이썬 개선 제안(PEP, Python Enhancement Proposal)서를 작성할 예정이다. 파이썬에서 스택리스 인터프리터란 이해하기 힘든 개념일 수도 있다. 아마도 이점이 바로 내가 반한 점인지도 모른다. 스택리스는 필자의 호기심을 발동시킨다. 스택리스(Stackless) 파이썬은 파이썬 인터프리터를 C 스택(C stack)으로부터 풀어내기 위한 프로젝트이다. 여기서 C는 C 프로그래밍 언어에 관련된 것이고, 스택(stack)은 무언가를 눌러 넣고 튀겨 꺼내는 리스트에 관련된 것이다. 이것이 무엇인지 여러분을 위하여 간략하게 설명해 보겠다.
C 스택은 C로 작성된 프로그램에서 함수들의 실행상태를 추적한다. 각 함수가 새롭게 호출되면 그 함수에 대한 포인터와 상태 정보가 그 스택위에 눌러 넣어진다. 새로운 함수가 종료되면 예전 함수가 튀겨 나오고 인터프리터는 튀겨 나온 그 함수의 처리를 재개한다.
보통 평범한 C 프로그램에서는 이렇게 하면 아주 쉽게 일을 처리할 수 있다. 그렇지만 파이썬은 이러한 종류의 실행 그 자체를 프레임(Frame)이라고 부르는 것에서 추적한다. 물론 파이썬이 대부분 직접 추적한다(단지 C 스택은 파이썬이 실행될 때 각 프레임에 대한 포인터를 유지하는데 파이썬은 그러한 C 스택에 너무 의존함). 그러나 이렇게 하는 것은 임시방편적인 방법이고 그 결과 현재 처리되고 있는 방식(current arrangement)에는 약간의 문제가 있을 수 있다.
C의 스택 크기는 고정되어 있다(따라서 파이썬 프로그램에서 호출할 수 있는 함수의 깊이에 제한이 생김). 깊이의 제한은 자기 자신을 반복적으로 호출하는 함수인 재귀(recursion) 함수를 사용하게 될 경우 큰 문제가 발생할 수 있다. 크기 제한이 없다는 것이 스택리스 파이썬의 큰 장점이지만 실제적인 혜택은 스택 그 자체를 조작하기를 원할 때 얻게 된다. 프레임(Frame)을 C 스택으로부터 분리하면 많은 트릭을 사용할 수 있다. 예를 들어 스택 위에 눌려진 함수들 사이를 뛰어 다닐 수 있고 그러한 함수들 간의 정보를 주고 받을 수 있으며 다중 스택(multiple stacks)을 유지하며 그것들을 서로 교환할 수도 있다. 스택리스는 코루틴(coroutine)에 사용될 수 있다. 코루틴은 스레드 프로그래밍을 대신할 고속 대안 프로그래밍이다. 스택리스가 되면 상태 머신(state machines)[1]를 쉽게 만들 수 있다. 그리고 이 스택리스 덕분에 콘티뉴에이션(continuations)을 사용할 수 있다. 콘티뉴에이션을 일컬어 크리스챤 디스머(Christian Tismer)는 "정보 과학계에 알려진 것들 중에서 가장 강력한 제어 구조"라고 기술하고 있으며 맥밀란(MacMillan)은 "머리를-폭발시키는 것(brain-exploding stuff)"이라고 지칭하고 있다.
여기서 우리는 스택리스 파이썬(Stackless Python)이라는 이름에 대해 다시 한 번 생각해 볼 필요가 있다. 이 이름은 오해의 소지가 있다. 스택리스 파이썬은 여전히 C 스택을 사용하지만 파이썬의 프레임(Frames)을 C 스택으로부터 분리하였기 때문에 위에서 언급했던 것과 같은 환상적인 트릭들을 모두 구현 할 수 있다는 말일 따름이다. 이러한 사실은 새로운 정보도 아니다. 지금 파이썬을 스택리스(stackless)로 만들 수 있기 때문이다. 크리스챤 디스머(Christian Tismer)는 스택리스 프로젝트를 유지보수하고 있으며 파이썬의 개발에 맞추어 파이썬을 스택리스로 만들기 위해 최선을 다해 패치를 유지보수하고 있다. 그렇지만 파이썬 개발 일정을 따라 잡으려면 시간이 걸린다. 이제 디스머가 스택리스 파이썬을 좀더 개선하는데 신경을 쓸 수 있도록 시간을 내주어야 할 시점이다. 많은 사람들이 파이썬 코어는 스택리스가 되어야 한다고 말하고 있다. 만약 스택리스가 파이썬의 코어에 들어가게 된다면 디스머는 더 이상 파이썬 개발을 따라잡기 위해 노력할 필요가 없다. 그리고 고든 맥밀란(Gordon McMillan)의 PEP 덕분에 어쩌면 실제로 그러한 일이 일어날지도 모른다.
스택리스 파이썬이 전혀 새롭게 느껴지지 않을 수도 있겠지만 파이썬 개선 제안(PEP)은 무척 새롭다. PEP는 파이썬 고유의 RFC[2]이다. PEP는 파이썬에 변경을 제안하는 과정을 공식적으로 절차화한다. 변경 사항을 제안하고 싶으면 주장을 정리해서 PEP로 발표하면 된다. 제안된 주장들은 논의 과정을 거쳐 결국 그 PEP는 수렴과 폐기, 둘 중 하나의 결과를 얻게 된다. 파이썬을 스택리스로 만들자는 요구를 하는 최종 담판 도중에 파이썬 개발팀으로부터 돌아온 대답은 명확했다. "PEP부터 작성할 것!"
고든 맥밀란(Gordon McMillan)은 스택리스를 위하여 PEP를 작성 작업을 시작할 것이다. 여러분이 열렬한 파이썬 사용자라면 파이썬 개선 제안(PEP)에서 눈을 떼지 않으리라고 생각한다. 파이썬 개선 제안(PEP)에 의견을 더 많이 줄수록 여러분은 미래의 파이썬의 개발 모습을 결정하는데 도움을 주게 된다. 상당히 논란을 불러 일으킨 PEP가 두 가지에 대해 간략하게 언급하겠다. 하나는 PEP 211으로서 선형 대수학을 수행하기 위하여 연산자들을 새로이 요구하고 있다는 것이며 다른 하나는 PEP 214로서 표준 print 서술문을 확장할 것을 제안하자는 내용이다. 스택리스(Stackless)의 내용을 담고 있는 PEP 219는 단순히 개요 상태만 서술해 놓았다. 맥밀란(McMillan)에 의하면 완성하기 까지 꽤 시간이 소요될 것이라고 한다. 스택리스(Stackless)를 더욱 확실히 포함시키기 위해 스택리스(Stackless) 그룹은 코루틴을 만들기 위한 간단한 API 완성을 위해 노력하고 있다. 코루틴(coroutines) API와 PEP 초안만 준비되면 생각할 필요도 없이(no-brainer) 스택리스(Stackless)를 코어에 추가해야 하느냐로 커다란 논쟁이 일어날 것이 분명하다.
[1] 상태 머신(State Machine): 각각의 상태(State)들을 어떤 조건에 따라 연결해 놓은 기계이다
[2] RFC(Request For Comments): 인터넷 표준 문서를 만들기 위한 검토과정에서 사용되는 문서
[참고] RFC의 유래: ARPANET(미국방성 프로젝트)을 만들 때 교수대신 대학원생들이 주도하고 있었기 때문에 표준(standard)이라는 용어는 너무 강해서 RFC라는 용어를 처음 사용했다고 함
고든 맥밀란(Gordon McMillan)은 파이썬 인터프리터의 코어를 스택리스로 만들기 위한 파이썬 개선 제안(PEP, Python Enhancement Proposal)서를 작성할 예정이다. 파이썬에서 스택리스 인터프리터란 이해하기 힘든 개념일 수도 있다. 아마도 이점이 바로 내가 반한 점인지도 모른다. 스택리스는 필자의 호기심을 발동시킨다. 스택리스(Stackless) 파이썬은 파이썬 인터프리터를 C 스택(C stack)으로부터 풀어내기 위한 프로젝트이다. 여기서 C는 C 프로그래밍 언어에 관련된 것이고, 스택(stack)은 무언가를 눌러 넣고 튀겨 꺼내는 리스트에 관련된 것이다. 이것이 무엇인지 여러분을 위하여 간략하게 설명해 보겠다.
C 스택은 C로 작성된 프로그램에서 함수들의 실행상태를 추적한다. 각 함수가 새롭게 호출되면 그 함수에 대한 포인터와 상태 정보가 그 스택위에 눌러 넣어진다. 새로운 함수가 종료되면 예전 함수가 튀겨 나오고 인터프리터는 튀겨 나온 그 함수의 처리를 재개한다.
보통 평범한 C 프로그램에서는 이렇게 하면 아주 쉽게 일을 처리할 수 있다. 그렇지만 파이썬은 이러한 종류의 실행 그 자체를 프레임(Frame)이라고 부르는 것에서 추적한다. 물론 파이썬이 대부분 직접 추적한다(단지 C 스택은 파이썬이 실행될 때 각 프레임에 대한 포인터를 유지하는데 파이썬은 그러한 C 스택에 너무 의존함). 그러나 이렇게 하는 것은 임시방편적인 방법이고 그 결과 현재 처리되고 있는 방식(current arrangement)에는 약간의 문제가 있을 수 있다.
C의 스택 크기는 고정되어 있다(따라서 파이썬 프로그램에서 호출할 수 있는 함수의 깊이에 제한이 생김). 깊이의 제한은 자기 자신을 반복적으로 호출하는 함수인 재귀(recursion) 함수를 사용하게 될 경우 큰 문제가 발생할 수 있다. 크기 제한이 없다는 것이 스택리스 파이썬의 큰 장점이지만 실제적인 혜택은 스택 그 자체를 조작하기를 원할 때 얻게 된다. 프레임(Frame)을 C 스택으로부터 분리하면 많은 트릭을 사용할 수 있다. 예를 들어 스택 위에 눌려진 함수들 사이를 뛰어 다닐 수 있고 그러한 함수들 간의 정보를 주고 받을 수 있으며 다중 스택(multiple stacks)을 유지하며 그것들을 서로 교환할 수도 있다. 스택리스는 코루틴(coroutine)에 사용될 수 있다. 코루틴은 스레드 프로그래밍을 대신할 고속 대안 프로그래밍이다. 스택리스가 되면 상태 머신(state machines)[1]를 쉽게 만들 수 있다. 그리고 이 스택리스 덕분에 콘티뉴에이션(continuations)을 사용할 수 있다. 콘티뉴에이션을 일컬어 크리스챤 디스머(Christian Tismer)는 "정보 과학계에 알려진 것들 중에서 가장 강력한 제어 구조"라고 기술하고 있으며 맥밀란(MacMillan)은 "머리를-폭발시키는 것(brain-exploding stuff)"이라고 지칭하고 있다.
여기서 우리는 스택리스 파이썬(Stackless Python)이라는 이름에 대해 다시 한 번 생각해 볼 필요가 있다. 이 이름은 오해의 소지가 있다. 스택리스 파이썬은 여전히 C 스택을 사용하지만 파이썬의 프레임(Frames)을 C 스택으로부터 분리하였기 때문에 위에서 언급했던 것과 같은 환상적인 트릭들을 모두 구현 할 수 있다는 말일 따름이다. 이러한 사실은 새로운 정보도 아니다. 지금 파이썬을 스택리스(stackless)로 만들 수 있기 때문이다. 크리스챤 디스머(Christian Tismer)는 스택리스 프로젝트를 유지보수하고 있으며 파이썬의 개발에 맞추어 파이썬을 스택리스로 만들기 위해 최선을 다해 패치를 유지보수하고 있다. 그렇지만 파이썬 개발 일정을 따라 잡으려면 시간이 걸린다. 이제 디스머가 스택리스 파이썬을 좀더 개선하는데 신경을 쓸 수 있도록 시간을 내주어야 할 시점이다. 많은 사람들이 파이썬 코어는 스택리스가 되어야 한다고 말하고 있다. 만약 스택리스가 파이썬의 코어에 들어가게 된다면 디스머는 더 이상 파이썬 개발을 따라잡기 위해 노력할 필요가 없다. 그리고 고든 맥밀란(Gordon McMillan)의 PEP 덕분에 어쩌면 실제로 그러한 일이 일어날지도 모른다.
스택리스 파이썬이 전혀 새롭게 느껴지지 않을 수도 있겠지만 파이썬 개선 제안(PEP)은 무척 새롭다. PEP는 파이썬 고유의 RFC[2]이다. PEP는 파이썬에 변경을 제안하는 과정을 공식적으로 절차화한다. 변경 사항을 제안하고 싶으면 주장을 정리해서 PEP로 발표하면 된다. 제안된 주장들은 논의 과정을 거쳐 결국 그 PEP는 수렴과 폐기, 둘 중 하나의 결과를 얻게 된다. 파이썬을 스택리스로 만들자는 요구를 하는 최종 담판 도중에 파이썬 개발팀으로부터 돌아온 대답은 명확했다. "PEP부터 작성할 것!"
고든 맥밀란(Gordon McMillan)은 스택리스를 위하여 PEP를 작성 작업을 시작할 것이다. 여러분이 열렬한 파이썬 사용자라면 파이썬 개선 제안(PEP)에서 눈을 떼지 않으리라고 생각한다. 파이썬 개선 제안(PEP)에 의견을 더 많이 줄수록 여러분은 미래의 파이썬의 개발 모습을 결정하는데 도움을 주게 된다. 상당히 논란을 불러 일으킨 PEP가 두 가지에 대해 간략하게 언급하겠다. 하나는 PEP 211으로서 선형 대수학을 수행하기 위하여 연산자들을 새로이 요구하고 있다는 것이며 다른 하나는 PEP 214로서 표준 print 서술문을 확장할 것을 제안하자는 내용이다. 스택리스(Stackless)의 내용을 담고 있는 PEP 219는 단순히 개요 상태만 서술해 놓았다. 맥밀란(McMillan)에 의하면 완성하기 까지 꽤 시간이 소요될 것이라고 한다. 스택리스(Stackless)를 더욱 확실히 포함시키기 위해 스택리스(Stackless) 그룹은 코루틴을 만들기 위한 간단한 API 완성을 위해 노력하고 있다. 코루틴(coroutines) API와 PEP 초안만 준비되면 생각할 필요도 없이(no-brainer) 스택리스(Stackless)를 코어에 추가해야 하느냐로 커다란 논쟁이 일어날 것이 분명하다.
[1] 상태 머신(State Machine): 각각의 상태(State)들을 어떤 조건에 따라 연결해 놓은 기계이다
[2] RFC(Request For Comments): 인터넷 표준 문서를 만들기 위한 검토과정에서 사용되는 문서
[참고] RFC의 유래: ARPANET(미국방성 프로젝트)을 만들 때 교수대신 대학원생들이 주도하고 있었기 때문에 표준(standard)이라는 용어는 너무 강해서 RFC라는 용어를 처음 사용했다고 함
TAG :
이전 글 : zlib 압축 라이브러리에 있는 버그
다음 글 : 업데이트 자바 API 맵
최신 콘텐츠