python

파이썬계에서 8월은 파이썬 3000으로 열기가 가득한 한 달이었습니다. 8월 초에 드디어 문자열의 유니코드화 작업이 완료돼서 py3k 브랜치로 머지되었고, 새 I/O 스택도 거의 제 모습을 갖췄습니다. 그리고, 약속을 지키기 위해 드디어 8월 31일(미국 서부시간 기준), 파이썬 3.0a1이 릴리스될 예정입니다.

최근의 변화를 보자면, 문자열 유니코드화는 이미 다른 곳에서 많이 보셔서 지겨울 정도이고, 최근 논란이 많았던 str.format이 얼마 전에 구현이 완료되어서 들어갔습니다. str.format이 그동안 파이썬의 마스코트(?)같았던 존재인 문자열 % 연산자를 대체할 예정입니다.

그리고, 아시아 컴퓨터교육계의 염원(?)이었던 국제화 식별자(i18n identifier)가 드디어 들어갔습니다. (여기에 대해서 OLPC 쪽에서도 관심을 보이고 있더군요.)

그렇지만 아직 토크나이저의 유니코드 처리가 좀 미숙해서 아주 특별한 조건에서만 제대로 동작하고 있는데, 3.0a2 전까지는 어디서든 유연하게 돌아가도록 고치려고 하고 있습니다.

그리고, 전체 디폴트 인코딩 뿐만 아니라, 소스코드 인코딩도 UTF-8이 디폴트로 바뀌었기 때문에, 소스코드를 UTF-8로 작성하면 따로 # coding: 을 쓸 필요가 없어지고, 요새 나오는 언어들하고 비슷하게 가고 있습니다. 🙂

파이썬 3000에 대해서는 전에 쓴 적이 있기 때문에, 구체적으로 다시는 안 쓰고 조만간 파이썬 3.0a1 출시 기념으로 스크린캐스트로 파이썬 3.0을 소개해 드리는 기회를 한번 만들어볼까 합니다. ㅎㅎ; ^_^

오늘은 요새 여러 블로그에서 인기를 끌고 있는
파이썬 합성 프로그래밍 환경(Synthetic Programming Environment for Python)
에 대해 간단한 리뷰를 해 봅니다.

그동안 파이썬에서 행렬 계산은 Numeric/NumPy, 기타 과학 연산은
SciPy 등 속도가 필요한 분야에 대한 해결책을 대체로 제시하고 있었지만
동적계획법(Dynamic Programming)이나 몬테카를로 시뮬레이션 같이 비교, 분기가 대량으로
발생하는 경우 파이썬만 가지고는 도저히 어떻게 해 볼 수 없는 한계가 어느 정도 있었습니다.
Pyrex는 뭔가 좀 답답하고 Psyco는 썩 만족스러운 단계까지
올라가지도 않고, 결국에 눈물을 머금고 C로 주요 코드를 짤 수 밖에 없었습니다.

그래서 몇 군데에서 시도했던 것이 파이썬에서 직접 어셈블리 코드를 실행시간에 생성해서
실행할 수 있는 JIT 어셈블러들이 등장했었는데요. 파이썬 코드랑 어셈블리랑 어색하게 결합하고
있다보니 인라인 어셈블리쓴 C보다 훨씬 더 어색해서 별로 쓰기가 유쾌하지는 않았지요.

합성 프로그래밍 환경(SPE)는 이걸 좀 더 우아하게 해결해보려는 라이브러리 입니다.
OpenSSL에서 사용하는 perlasm같이 스크립트 언어의 자체 문법으로
약간은 추상화된 방법으로 명령을 작성하면, 그 코드가 실행되면서 어셈블리 코드가 생성되고
그게 결국 실행되는 방법입니다. 너무 추상화하면 C나 다름 없으니, 거의 1:1로 맞춰볼 수 있을 정도로
간단하게 처리했지만, 사실 “합성(synthetic)”이란 말에서 드러나듯, 파이썬 문법에 대체적으로
끼워넣어서 재사용성을 매우 높일 수 있다는 점이 장점입니다.

간단한 perlasm에서도 풀어쓰기(unroll)이나 스택 셋업, 인수 대량 전달, 디버그 출력,
클린업 같이 많은 작업들을 라이브러리화 해서 쓰고 있어서, 실제 생성되는 최종 어셈블리 코드보다
훨씬 사람이 보기 쉽고 재사용할 수 있는 코드를 씁니다. SPE에서는 perlasm에서 쓰는 것 뿐만 아니라
벡터연산을 훨씬 쉽고 간단하게 쓸 수 있게 해 주기도 하고, 간단하고 단순노동적인 조건문이나
오프셋 계산 같은 것들을 우아하고 보기 쉽게 쓸 수 있도록 해 줍니다. 게다가 파이썬 코드
안에서 섞어 쓸 수 있기 때문에, 귀찮게 왔다갔다 할 필요도 없습니다.

결국, SPE의 모토는 “Skipping C”라고 하는데, 두 가지 의미가 있습니다. 하나는 원래 파이썬이
C언어로 된 인터프리터, 익스텐션 라이브러리, 컴파일러 등을 통해서 기계어로 실행(+번역)되어
왔는데, 이를 건너뛰어서 그냥 파이썬에서 바로 기계어를 쓰자는 의미로 볼 수 있고,
나머지 하나는 개발할 때 C언어로 개발할 필요를 많이 줄여서 C는 쓰지 말자 뭐 이런 의미로
볼 수도 있겠죠. 즉, 평소같으면 C로 상당수 기반을 만들어서 파이썬에서 사용하는 방식을 채택할
경우라도 파이썬과 SPE에서 제공하는 어셈블리를 쓰면 C 안 쓰고도 비슷하거나 빠른 속도를
낼 수 있다는 얘기입니다.

많은 분들이 이쯤 되면, 속도가 상당히 궁금하실텐데, 간단하게 1000만까지 숫자를 더하는 프로그램을
작성했을 때, 파이썬으로 작성된 코드가 3.64초, 내부 코드 및 자료구조가 모두 C로 작성된
NumericPython으로 0.054초, SPE로 0.019초라고 합니다. (SIMD는 사용하지 않음)
요새 C 컴파일러가 좋긴 하지만, 사람은 알고리즘까지도 변경하면서 최적화할 수 있고, 굳이
프로파일링 하지 않고도 어느 정도까지는 분기 수요를 예측할 수 있다는 점 때문에
아무래도 같은 시간 노력하면 짧은 코드는 SPE로 하는 어셈블리가 C보다 이렇게 빠를 수 있지 않을까 싶군요.
(물론, 요새 유행하는 프로파일링 컴파일러를 빡시게 돌리면 C나 SPE나 결국 비슷한 최고속도에 도달하겠지만요.)

SPE가 주 대상으로 하는 것은 아무래도 과학계산과 멀티미디어 연산이 되겠지만, 사실 과학연산에서
어셈블리를 다룰 정도로 컴퓨터 구조에 대한 지식이 있는 연구자의 수가 그렇게 많지 않은 것을 생각해 보면
기계 지식없이도 어셈블리를 쉽게 할 수 있게 라이브러리가 많이 확충되어서 “합성”만 해도 프로그램이 되면 아주 좋겠네요.
물론, 파이썬에서 도저히 어떻게 해결할 방법이 없던 한가지 프로그램 주제를 비교적 깔끔하게 해결해버렸다는
점에서는 벌써 상당한 가치가 있는 시도로 보입니다.

(참고사항: SPE의 구현인 CorePy는 현재 PowerPC만 지원하고 있고, 라이선스도 오픈소스가 아니라 시험용으로만
사용할 수 있는 라이선스이기 때문에, 이걸로 당장 뭔가 해 보기는 힘듭니다. 🙂

입추 기념(;;)으로 파이썬 마을 번개를 오랜만에 합니다. 사실 그동안 제가 대전에 있어서 별로 모임을 못 가서, 휴가 틈을 타서 한번 서울 갈 핑계를 만들어보고자.. ^_^;;

• 일시: 2007년 8월 10일(금요일) 오후 8시~
• 장소: 포스코사거리 JS타워 야후코리아 10층 서니베일 회의실
• 내용: 오후 8시~9시30분 – 파이썬 3000과 관련된 잡담과 토론. 그 이후 주변 어딘가에서 뒷이야기
• 참가비: 뒷풀이 비용에서 1/n 더치, 잡담은 참가비 없음 (야후코리아에서 간단한 다과 제공)

참가신청은 파이썬마을 자유게시판에서 선착순 20명 받겠습니다.
장소가 한정되어 있어서 딱 자를 계획이니 꼭 참가하실 수 있는
분들만 신청해 주세요~ 🙂

요새 인텔에서 80코어 CPU를 공개할 정도로 점점 병렬 프로세싱이 싼 가격과 작은 크기로 내려올 것 같은 분위기가 많이 돌고 있습니다. 저도 요즘 학교에서 하는 실험이 CPU 20개에 분산해서 실행해도 하루 정도 돌아가는 것이다 보니, 컨커런트 프로그래밍이 기본적으로 지원되는 언어들에 대한 소식에 요즘 상당히 솔깃 하고 있는데요. 으흐흐 하여간 파이썬은 GIL 때문에 여러모로 불안할 따름입니다;

그러던 중, 파이썬 마을에 어떤 분께서 작업을 N개의 프로세스로 분산해서 실행하는 방법을 질문해 오셔서 답글을 달다가, 예제로 만들어 본 것이 보고 있으려니 제너레이터로 만들면 상당히 깔끔해 질 것 같아서, 잠시 제너레이터로 만들어 봤습니다. 흐흐

긴 시간이 걸리는 같은 종류의 작업을 여러 데이터에 적용하는 경우를 가정하고 만든 것인데요, 우선 용례를 보면 이렇게 하면 좋겠다 생각이 들었습니다.

보통 이런 것들은 threads.start_new_thread()처럼 뒤에 함수를 줘서 그게 실행되는 경우가 많은데, 그러면 조그만 작업도 다 함수로 만들어야 해서 코드가 왔다갔다 해서 헷갈리죠. 그래서 for루프 안에 넣었는데, 실제로 for 안쪽이 여러 번 돌지는 않고, 각각이 별도의 프로세스로 최대 4개가 동시에 돌아가게 됩니다. 그래서 이 인터페이스에 맞게 구현해 보면 요렇게..

이렇게 만들고 나니, 왠지 결과 데이터를 메인 프로세스에 모두 모아오는 기능이나 프로세스 재활용 같은 기능도 넣어 보고 싶고 with 절로 해 보고 싶기도 했지만.. 일단은 돌아가기에 귀찮아서.. 흐흐 -ㅇ-;; with로 하는 경우에는 for와는 다르게 메인 프로세스에서 하위 블럭을 생략할 수 없어서 메인 프로세스도 일을 해야하다보니 좀 더 복잡하겠더군요..

그런데, 사실 이걸로 열심히 놀고보니, 원래 쓰던 셸 스크립트로 하는 방법이 훨씬 간단한 것 같아서 허탈합니다. 하하;;;; ㅡ.ㅜ

그동안 파이썬에서는 변수 이름, 함수 이름, 클래스 이름 등등에서 영문 알파벳과 숫자, 밑줄만 사용할 수 있었습니다.
전문 개발자들이야 영어가 필수이다보니 그냥 쓰면 된다지만, 어린 애들이나 도구로 프로그래밍을 하는 분들은
영어로 써야한다는 것이 엄청난 어려움으로 다가올 수 밖에 없습니다. 주석을 변수이름에 녹인다는 기법만 적용하려고
해도, 주석은 한글로 쓸 수 있다지만 변수 이름을 한글로 쓰지 못하면 녹여내지 못하고 결국 초딩용 코드 a, b, c가
등장하게 돼서 암호가 돼 버리죠 =.= 그래서 그동안 비영어권 국가 개발자들은 유니코드 식별자의 필요성을
계속 얘기하고 있었고, 한국, 중국, 일본 같은 경우에는 각각 비영어 식별자를 지원하는 패치를 배포하기도 했습니다.

그러던 중, Python3000을 위해 논의되어 왔던 파이썬 비-아스키 식별자 (non-ASCII identifier)가 지난 5월 27일에 드디어 통과되었습니다.
오랫동안 거의 “내 눈에 흙 들어가기 전에는…” 수준으로 비-이스키 식별자 (밑에서는 유니코드ID로 표기)를
싫어하던 귀도가 그동안 내 아들들에게도 자국어로 프로그래밍할 수 있는 기회를 주고 싶다는 마틴, 발터 등의
여러 비영어권 개발자들의 노력으로 설득당해버렸군요. 🙂 (물론 이 뒤에는 무려 메일 1000개가 넘는
여러가지 기술/정책/정치적인 토론이 있었습니다.)
아직 PEP에서는 상세하게 다뤄지지 않았는데, 일단은 PEP번호는
PEP-3131입니다. (이렇게 내용 없는 PEP가 accept되기는 처음이 아닐까 싶은데, PEP로 정리만
되지 않았지 토론 내용 여기저기에 충분히 의견의 합의는 있었습니다.)

그럼, 한중일에서 그냥 2~3줄 패치해버리는 것으로 간단하게 됐던 한글 허용을 도대체
파이썬에서는 무엇때문에 이렇게 논란이 많은지 고민하실텐데요, 모든 문제의 원천은
소스파일마다 인코딩이 다른 상황 때문에 발생합니다. 소스코드끼리 인코딩이 다를 때
서로를 참조하는 방법을 통일시키려면 시스템 내부의 인코딩을 통일할 수 밖에 없는데,
이것으로 유니코드를 채택하다보니 유니코드에서 발생하는 여러가지 특징들이 문제로 다가오게 됩니다.
한중일의 패치는 그냥 허용 영역만 푼거라서, 사실 이런 것에 대해서는 대책없이 그냥 임시방편으로
풀어놓았던 것이지요.

대표적인 문제를 보자면, 우선 정규화(normalization)문제가 있습니다. 정규화는 똑같은 논리적
글자가 유니코드에서 여러가지 방법으로 표현되기 때문에 발생하는 문제인데, 예를 들어서
한글의 경우에는 “한(U+D55C)”과 같이 완성형으로 표현하는 방법도 있고, “ㅎㅏㄴ(U+1112 U+1161 U+11AB)”같이 조합형으로 풀어서 쓰는 방법이 있습니다. 앞과 같이 최대한 뭉쳐서 표현하는 방식을
NFC(Normalization Form C)라고 부르고, 뒤와 같이 최대한 풀어서 표현하는 방식을
NFD(Normalization Form D)라고 부릅니다. 둘 중 하나로 표현하면 논리적으로 같은 글자가
코드로도 똑같이 표현이 되니까, 코딩 방식을 다르게 했다고 이름이 같은지 모르는 MacOS X 파일시스템같은
상황이 없어집니다. 파이썬에서는 여러모로 내부 목적에 적합하다고 판단하여 NFC로 결정하였습니다.
사실 NFD와 NFC 사이에서는 간단하게 결정되었지만, NFKC와 NFC중에 무엇을 택할지는
좀 애매한 문제여서 토론이 있었는데, 결국은 손실 없이 최대한 줄여 쓰는 NFC를 채택하게 되었습니다.
(NFKC는 손실을 감수하고 줄여씁니다.)

그 외에도 역시 거의 유니코드 글자 속성 전 영역에 대해서 문제가 발생하는데, 이런 것이 있습니다.

• Breaking: 각 글자가 앞 뒷 단어를 떼어주는 역할을 하는지 속성을 지정합니다. 예를 들어,
  한글{ZWNBS}메롱 이라면 “한글{ZWNBS}메롱” 전체가 한꺼번에 변수 이름이 돼야 하지만,
  한글{ZWBS}메롱 이렇게 썼다면 “한글” “메롱”이 따로 따로 변수 이름으로 인식돼야 합니다.
  (ZWBS=Zero-Width Breaking Space, ZWNBS=Zero-Width Non-Breaking Space)
  그런데, ZWBS같은 경우에는 눈에 안 보이기 때문에, 사람 눈으로 파이썬 소스를 완벽히 분석할
  수 없다는 문제가 발생합니다. 그렇지만, 이런 건 변태들이나 하겠지;; 하고 어쩔 수 없는 문제가
  아닐까 하는군요.
• 글자 속성: 아스키 문자영역에 대해서는 몇 글자 안 되다보니, 어떤 것이 부호이고, 어떤 것이
  글자인가가 상당히 명확하지만, 유니코드까지 가게 되면 명확하게 숫자, 문자인 것이 있는 반면에
  어떤 것은 숫자인것 같기도 하고 아닌 것 같기도 한 것들이 수도 없이 많습니다. (예를 들어,
  홍콩지역 기수법 문자라던지, 네모 안에 숫자로 들어있는 것 같은 것들은 유니코드 데이터베이스에서는
  여러가지 속성이 같이 기록되어 있지만, 프로그래밍 언어 측면에서는 숫자로 인정해야 할지 변수 이름 글자로
  인정해야 할지 무지 애매하죠.. 10진법을 뛰어 넘는 숫자까지도 존재해서..) 그래서 각 글자 속성에
  대해서 어떤 것을 변수 이름으로 인정하게 하고, 어떤 것을 허용하지 않을지 결정하는 것이 중요한데,
  더욱 애매한 것은 유니코드 버전이 올라가면서 글자가 추가되거나 기존 글자의 속성이 바뀌는 경우도
  있다는 것입니다. -ㅇ-;; (그래서 파이썬에서 지원하는 유니코드 버전이 바뀌면 소스 파싱 방법도 바뀌고..)
• 왼쪽으로 쓰는 문자체계: 아랍어나 히브리어 같은 경우에 오른쪽에서 왼쪽으로 쓰기 때문에,
  유니코드 처리에서도 상당히 특별하게 처리해 줘야 합니다. 여기서 이제 파이썬 소스코드를 보는 쪽 뿐만
  아니라 소스코드를 출력하는 부분이 있는 traceback이나 IDLE등 수많은 곳에서 오른쪽에서 왼쪽으로
  쓰는 처리를 해 줘야하게 됩니다.

유니코드 쪽의 문제 뿐만 아니라, 파이썬에서 유니코드ID를 디폴트로 허용할 것이냐, 소스쪽에서
옵션으로 풀것이냐, 아니면 파이썬 명령행에서 풀게할 것이냐 등등 디폴트 설정에 관해서 의견이
많이 있었는데, 이건 아직 의견이 팽팽하게 맞서고 있어서 결정되지 않았습니다. 심지어 어떤 사람들은
위에서 언급된 것들 (NFC냐 NFKC냐, 문자 속성 선택 등..)을 런타임에 결정할 수 있게 하자는
사람도 있는데.. 역시 사람들 의견은 정말 다양하군요 -ㅇ-;

그 외에도 여러가지 기술적 문제들이 남아있지만, 결국 정책적으로는 귀도가 파이썬의 내부
파이썬 코딩 스타일 가이드인 PEP-8에서
절대 파이썬 자체 코드 안에서는 ASCII 이외의 문자를 쓰지 말도록 정하였고, 광범위한 개발자들이
참여하는 모든 오픈소스프로젝트에서도 이 규칙을 채택하도록 권고하는 것으로 결정했습니다.

이제 파이썬3000이 나오면 왠지 교육용으로 추천해도 마음에 찔리는 게 없을 것 같아서 무척 좋군요! 🙂

Maya, Google, Civilization IV, Battlefield 2,
BitTorrent,
EVE Online,

Corel PaintShop Pro,
NASA,
YouTube,
MIT CS101

대충 보기엔 별 공통점이 없어 보이는 프로그램 이름들과 회사(기관)이름들이 있습니다. 이들은 무슨 공통점이 있을까요? — 뻔한 퀴즈지만 파이썬을 주된 도구로 채용한 프로그램이나 기관들입니다. 🙂 이미 익숙하게 알려진 것들이 많지만 얼마 전에 우리에게 친근한 새로운 용례가 또 추가되었습니다. 바로, 다음 웹검색 [1]에서 파이썬을 프론트엔드에 도입한 것입니다! (추측컨데 크롤러와 인덱스 빌더 등에서도 많이 사용했을 거라고 생각됩니다.)

이제 파이썬은 대안언어를 넘어서서 제 자리를 확실히 잡은 듯 합니다. 요즘 과학 논문에서 파이썬으로 된 도구를 보는 것은 아무렇지도 않은 일이 됐고, 이제 학교에서 어떤 과목 프로젝트를 하다가, 같은 조원이 파이썬이란 언어가 있는데 자기가 써보니 괜찮다더라 하면서 소개를 해 줄 정도로 잔뿌리를 널리 폈습니다.

그래서 2000년부터 최근까지의 파이썬 관련 행사들이 대부분 소개를 주목적으로 했다면, 이제는 파이썬을 활용하는 사람들이 새로운 만남을 통해 동기와 아이디어, 새로운 시각을 얻을 수 있는 모임이 필요할 때가 아닌가 생각됐습니다.

마침 서울에 가고 싶은데 핑계도 없고 해서 –; 뭔가 행사를 한 번 만들어 보고자 생각을 좀 해 봤는데, 그냥 옛날 스타일 컨퍼런스도 식상하고, 요새 많은 그냥 언컨퍼런스도 부담이 많고 해서 올해 초의 한국 루비 포럼 세미나의 형식을 약간 따 와서 이런 것을 생각해 봤어요.

먼저 간단한 파이썬 문제 — 프로그래밍 학습에 쓰이는 장난감
문제 뿐만 아니라, 각 활용 분야별 특성을 잘 나타내는 아주 작은 장난감 문제들 — 를 웹에서 모집합니다. 모집은 물론 공개된 방법으로 누구나 올릴 수 있고, 서로 평가해서 높은 순위에서 적당히 몇 개를 추립니다. 여기서 추려진 문제는 행사 시작 1주일 전 공시되어서 행사 참가자들은 자기가 참가할 세션의 문제를 혼자서 풀어봅니다.

그리고 행사 당일에는 OST 형식의 자유토론(과 미리 정해진 코너가 혼합되어)으로 해당 장난감 문제를 푸는 방법에 대해서 참가자들이 돌아가면서 설명해 보고, 거기서 파생되는 테크닉과 여러 습관, 기술, 관련 소식, 경험 등을 얘기합니다. 너무 주제가 산으로 가거나 제한 시간이 지나면 일단 중단하고, 누군가가 다음 세션으로 또 그것을 이어갈 세션을 만들기도 하고 여러 개로 나눠질 수도 있겠죠.
이런 방식의 세션을 제약 없이 연속적으로 3시간 정도 진행하고
잠시 쉬는 시간이나 적당한 공통 세션 후에 다시 또 3시간. -ㅇ-;

특히 게임, 과학계산, 시뮬레이션, 금융전산, 사회학정보처리 분야 같이 기존의
프로그래밍 언어 행사에서 포용하기 힘들었던 분야의 분들이 장난감 문제를 뿌리로 해서 얘기를 뻗어나갈 수도 있겠다는 점에서는 긍정적인 효과가 있지 않을까 생각됩니다.

음.. 물론 적당한 좋은 형태가 더 있다면 병행할 수도 있고~ 이런 행사 어때요? ^_^

아이디어, 제안, 행사지원, 진행자원봉사 지원 등 어떤 의견이든 환영합니다!

오늘은 통계 숙제를 하다가, math.e math.log 이런 것 누르려다 보니, import math하기가 갑자기 무지 귀찮았습니다. 맥에서는
파이썬 대화모드는 거의 항상 WidgetTerm에 항상 띄워두고 쓰지만, math나 urllib같이 늘 쓰는 모듈을 쓸 때에도 import하고 쓰는게 그렇게 귀찮았구나~ 하고 옛날 생각도 나면서.. 흐흐

그래서 예전에 올라왔던 자동 들여오기 PEP가 생각나서 봤는데, 게으른 모듈(lazy module)을 일일이 다 만드는 방법으로 처리해서, 소스가 상당히 길고 설치하기가 귀찮더군요. 그래서, sys.excepthook을 써서 어떻게 NameError를 잘 지지고 볶으면 될 것 같아서. 한번 해 봤습니다~

실행해 보면~

적당히 디스크 어딘가에 풀어두고, PYTHONSTARTUP 환경변수로 파일이름(전체경로)를 써 주시면 되겠습니다. 셸 프로파일에 적어주시면 편합니다~ ^^

주의사항: 여러 줄 블럭이거나 한 줄에라도 부작용(side effect)이 있는 코드이면 원래 의도와 다르게 동작할 수 있습니다.