python

요즘 영 머리 안 쓰는 일만 했더니 머리가 굳어가는 기분이 들기 시작해서, 2.4에서 새로 들어가는 collections 모듈의 heap타입을 한 번 구현해 보고 있습니다. heap타입은 일단은 피보나치 힙으로 구현하도록 제안되어있는데, 나중에 같거나 좋은 복잡도를 갖고 아모타이즈드 분석에서 나은 알고리즘이 있다면 다른 걸로 교체할 수도 있다고 합니다. 그래서 일단은 일반적인 힙 작업들을 메쏘드 인터페이스로 만드는 것이 가장 먼저 정해져야할 작업입니다.

옛날에 역시 피보나치 힙으로 구현된 파이썬 모듈인 devel/py-pqueue 소스를 봤을 때 앞쪽 주석이 “이 알고리즘은 매우 더러우니 소스 보고 이해할 생각은 하지 마시오” 식의 문구가 써 있어서 당황해서 안 봤던 기억이 있는데, 웹에서 애플릿 애니메이션을 몇개 보면서 문서를 보니 그런대로 이해는 가는군요. 요즘 세상이 좋아져서.. 흐흐;

우선, insert, min, extractmin은 구현했는데, 이제 decreasekey, union, iterator, delete같은 것만 구현하면 될 것 같습니다. 그런데, 지하철에서 오는 내내 생각하다가 내릴 곳을 놓칠뻔 한 심각한 고민이 문서들을 읽어봐도 해결되지 않는 것이 하나 있습니다. decreasekey 작업을 수행할 때 트리를 가지에서 뚝 떼서 밑둥에 붙이는 작업이 일어나는데, 그럼 그 원래 붙어있던 자리의 degree가 틀린 값을 기록하고 있게 된다는.. 그러니까 원래 degree 4인 것과 degree 1인 자식들이 붙어있던 녀석은 degree가 5가 기록이 되어있겠지만, degree 4인 자식이 decreasekey하던 중 떨어져 나가면, 그 가지는 실제로는 degree 2지만, 값은 5가 기록되어 있게 된다는 것인데.. 이렇게 되면, consolidate하는 과정에서 전체 원소 개수로 추정하는 maxdegree를 넘어 버리는 노드가 나올 수도 있을 것 같고, 무지 컸다가 막 decreasekey되면서 뚝뚝 떨어져 나온 힙이라면, 여기저기 실제 degree보다 엄청 높은 녀석들이 분산돼 있어서, 실제 효율이 많이 떨어지지 않을까 하는 걱정에 휩싸입니다. -.-;;; 흐흐흑… 혹시 피보나치 힙과 친한 분들은 꼭 알려주세요;

-> 후기: 알고보니 degree를 제가 잘못 이해한 것이네요; degree는 높이가 아니라 그냥 자식 노드 갯수를 뜻하는 것이었네요~ (아히 부끄러워라;; )

지금까지 구현한 소스는 http://openlook.org/cvs/collections/ 에 올라가 있습니다. 남은 메쏘드 구현이 끝나면 SF에 올릴 생각입니다.

파이썬 마을은 지금 phpBB로 운영되고 있는데, 처음 도입할 당시에는 가장 적합했기에 쓰기 시작하기는 했지만, 아무래도 Zope나 Quixote같은 좋은 웹 프레임웍이 있는 파이썬 계열 사이트에서 계속 php를 쓰는 것은 좀 찝찝~~해서 바꾸려고 계속 생각하고 있었습니다.

오늘 찾아보니 phpBB 비슷한 형태의 Zope 기반 게시판 프러덕트가 fcForum과 CMFBoard를 찾았습니다. 구글 검색 결과로는 CMFBoard가 4배 정도 참조가 많이 된 걸로 봐서는 CMFBoard가 CMF의 후광덕에 좀 인기가 좋은 듯 합니다.

대충 웹에서 보니 둘 다 괜찮은 것 같아서, 앗싸~ 하고 깔아봤는데, 아 이럴수가 흐흐.

• CMFForum – 속도가 굉장히 느립니다. 데모 사이트를 봤을 때 유난히 느리길래, 회선이 안 좋은가 했더니, 실제 깔아 보니 상상을 초월하게 느렸습니다. -o- 코드는 다른 CMF 프러덕트들처럼 엄청난 수의 (거의 20개에 육박) 의존 프러덕트가 있어서 그런지, 코드는 상대적으로 많이 간단했고, 관리도 수월해 보였습니다. 국제화 프레임웍이나 템플릿도 아주 잘 돼 있어서 유지보수성에서는 아주 좋아보였는데.. 그렇지만 Plone 때문인지 도저히 참을 수 없을 무거운 동작은 참..;;

• fcForum – 상대적으로 속도가 아주 빠르고, CMFForum과는 다르게 캐쉬구조도 채택하지 않았음에도 거의 10배는 빠르네요. 그렇지만, 다른 일반 프러덕트들과는 달리 코드를 모두 Script (Python) 타입 오브젝트로 작성하는 바람에, 코드를 직접 설치되는 폴더에 복사해버리기 때문에, 심지어 프러덕트를 지워버려도 작동합니다. (인스톨용 프러덕트 –;) 그리고, Zope외에는 쿠키관리하는 간단한 프러덕트만 의존하고 있어서, 깔기도 참 편하긴 한데, 국제화가 Script 하나 안에 if 로 묶여있는데다가, 조잡한 다국어 지원을 넣고 있어서, 유지보수가 아주 힘들어 보였습니다. 그리고, 각 페이지들은 스크립트들 1개씩이 할당되어 있어서, 뭔가 한꺼번에 코드를 수정하기도 힘듭니다. -.- 므흐 결국은 뭐 PHP+Smarty구조랑 어느 정도 비슷한 것인데, 코드 자체의 문제를 빼고는 겉으로는 관리 인터페이스도 아주 훌륭하고 속도도 빨랐습니다.

CMFForum은 느려서 쓰기가 무리이고.. fcForum은 아주 쓰기는 좋은데 코드가 유지보수가 불가능해보이고 국제화 문제가 있어서, 고민을 좀 더 해 봐야겠습니다~

그동안 침체되어 있었던 파이썬마을을 다시 띄워보는 게릴라 세미나를 다시 시작했습니다.~ 으흐흐. 주제는 “이터레이터와 제너레이터” 였는데, 사실 핑계이고 그냥 한번 모여보자는 그런 것이었죠. 흐흐 생각보다 많은 분들이 와 주셔서 정말 재미있었습니다.

에헤헤. 세미나를 참석 못한 분들을 위해서 자료 공개.

• 프리젠테이션 파일 (애플 키노트용)

• 프리젠테이션 파일 (PDF)

• 중간에 쓰인 제너레이터 예제 1

• 중간에 쓰인 제너레이터 예제 2

다음번 세미나는 더욱 살떨리는 주제로 재미있는 모임 했으면 좋겠습니다.

ACCU 2004 컨퍼런스에서 Armin Rigo씨가 발표한 프리젠테이션이 엄청난 반향을 일으키고 있습니다. 그래 파이썬 프로그래머라면, 프리젠테이션이 이정도는 해야하는건가!

화면이 뭔가 좀 이상하죠? 바로 PyGame으로 애니메이션 프리젠테이션을 만든 것! 시작하면 Rigo Production로고가 나오면서;; 레밍이 무턱대고 걸어가면서 걸어가다가 풍 빠지는데, Penty(Pentium assembly얘기 일까요?)는 그냥 무식하고 경로대로 걸어가다가 크래쉬난다고 그럽니다. 그 뒤에 보글보글이랑 높은 레벨에 나오는 귀신이랑 캐릭터가 퐁퐁 뛰어다니면서 소스가 1줄 1줄 진행될 때마다 CPy와 Psyco등이 각각 내부적으로 어떤 일이 있는지 자세히 알려줍니다.

으흐. 그동안 평범하고 정적인 프리젠테이션으로 알아보기도 힘든 발표를 늘 하고 있었는데, 이렇게 애니메이션으로 설명하니까, 머리에도 쏙쏙 들어오고 진짜 최고입니다. 파이썬이 아니라면 어느 커뮤니티에서 이런 시연을 볼 수 있을까요. ^.^ 저도 이제 pygame을 열심히 배워서;; 다음 프리젠테이션에는 꼭;; Armin도 사실 그동안 많이 psyco에 대해 설명을 해 봤지만, 이번에 최초로 청중들이 이해했다는군요;; 크흐;;

여기서 볼 수 있습니다: http://psyco.sourceforge.net/

업동씨 결혼식갔다가 와서 시간이 좀 남아서 PEP309에 제출된 다른 언어의 “curry” 함수를 훔쳐온 아이디어, partial을 한번 구현해 봤습니다. 요즘 회사에서 HTML그리기 등등 잡무만 했더니 집에서 생산력이 아주 높아져서.. 언젠가 Ken Thompson씨던가가 말씀하셨듯, 역시 회사에서 잡무가 늘어날 때가 오히려 창의적 성취는 늘어나는 묘한 관계가 있는건지도요 -.-a

partial은 nohmad님의 말씀에 따르면 C#에도 partial이란게 있는데, 여기의 partial과는 좀 다른 버추어 메쏘드 만으로 이뤄지는 클래스 비스무리한 것을 뜻하는 키워드라는군요.. PEP309의 partial은 함수 호출의 일부만을 미리 정의해서 callable object로 만들어주는, anonfunc나 operator.itemgetter랑 약간 비슷한 류의 도구입니다. 예를 들면

요런 식으로, partial의 첫번째 인자는 함수이고, 두번째부터는 인자랑, 키워드 인자들이 들어갑니다. 그러면, 그 인자들이 함수에 나중에 적용되게 되는데, sorted의 원래 reverse 키워드의 기본 값이 False인데, 요렇게 True로 바꾼 것을 쉽게 만들 수 있겠죠~

partial은 타입 인자가 fn, args, kw 세개가 있는데, 셋을 만들고 나서 바꿀 수도 있습니다. 예를 들면,

믓흥믓흥. 뒷 인자를 못 바꾸는 약간 불편한 것은 있지만, 그래도 anonfunc에 비하면 논리적, 설게적으로 아주 깔끔하고 좋은 느낌입니다. +_+

패치는 요기에 제출했습니다.

파이썬 2.3에서는 본격적으로 소스코드 인코딩을 지원하기 시작해서 이제 소스코드 안에서도 u’한글’ 이런식으로 C 처럼 한글을 유니코드로 바로 쓸 수 있게 되었습니다. 그런데, 인터랙티브 인터프리터 환경에서는 무조건 ISO-8859-1로 인식해 버리는 바람에, euc-kr 터미날에서는 이런 사태가 벌어집니다.

분명히 stdin의 인코딩은 euckr인데! 그걸 갈갈이 쪼개서 iso-8859-1로 넣어버리는 것인데, 사실 50명이 넘는 파이썬 개발자 중에서 iso-8859-1로 쓸 수 없는 모국어를 가진 사람은 2~3명밖에 안 되는 터라, 아무도 사실을 모르고 2.3에서 넘어간 것 같기도 하고.. (사실 iso-8859-1을 변수이름에 쓸 수 있는 꽁수도 있습니다. 흑흑 -.-…)

하여간, 그래서 이 문제를 해결하기 위해서 좀 삽질을 해 본 결과, 인터랙티브 인터프리터는 1줄씩 Parser/tokenizer.c의 tok_nextc함수에서 tok->prompt가 != NULL일 경우에 들어가는 루프에서 처리되는데, 파일에서 소스를 읽는 경우는 StreamReader로 처리하고 있는 반면에, 프롬프트에서 읽을 때는 전혀 디코딩 처리를 안 하고 있어서 결국은 iso-8859-1로 하고 있는건데, 일단 decode->encode하도록 약간 수정을 해서 트래커를 제출했습니다. 소스 파일에서 읽을 때는 Stream으로 읽은데 반해, 프롬프트에서 읽을 때는 조각 조각 디코드, 인코드를 하도록 했기 때문에, hzgb같은 행간 시퀀스가 있는 경우에는 완전한 지원이 불가능하지만, 사실상 그런 인코딩을 터미날에서 쓰는 사람은 없다고 봐도 괜찮다는 판단으로 그냥 저렇게 만들었습니다. -ㅇ-; (hzgb를 대체 어떻게 지원하지!;;)

아직 리뷰는 안 되었으니, 혹시 2.4 쓰고 계신 분들은 패치를 받으셔서 한번 테스트해봐 주세요 (처음 테스트를 도와주신 nohmad님께 감사~)

므흐흐. 스택리스 파이썬 개발자로 등록되었습니다. 며칠전에 amd64로 포팅한 것 때문에 해볼텨라고 메일이 와서, 별로 스택리스 내부는 잘 모른다고 고사했는데, 티스머씨가 그냥 하고 싶은 것만 하면 된다고 해서.. ^^;;

앞으로 스택리스 컨텍스트 스위처를 sparc64, ia64로 포팅하는 것같이 시시껄렁한 일을 일단은 주로 할 예정입니다.~ 아 근데 오리지널 파이썬과는 달리 쉘 계정도 주고 IMAP 계정도 주고 서비스는 짱이네요~ 므흐흐.. 근데 LC_ALL=C 로 바꿨는데도 자꾸 에러메시지가 독일어로 나오는 쉘이란 참;;;

이번 IETF 만우절 RFC가 전지적 프로토콜 요구사항이라는 좀 재미없는 게 나왔는데, 파이썬쪽에서는 재미있는 게 몇개 나왔군요.

• From python-dev, space vs. tab controversy finally settled

Guido가 스페이스와 탭 인덴트의 오랜 논쟁을 끝내고 스페이스를 표준으로 정해버릴 거라는 얘기.

• ANNOUNCE: ‘goto’ for Python

파이썬에 과감히 goto, comefrom, label 키워드를 추가해버려서 goto가 되게 만들었다는 발표문. 이건 정말로 작동한다! 헉헉. (감동 ㅠ.ㅠ)

• Microsoft making Python.NET

Microsoft가 Visual Python.NET 베타를 발표했다는 썰렁한 얘기. 진짜로 Visual Python.NET이 나왔다는 걸 모르고 뻥때린듯~

특히 goto는 뭔가 새로운 지평을 연 획기적인 April Fool같네요. 내년은 구현 없는 April Fool은 무효!

작년 Miguel의 MS메일링에서의 Jim Hugunin의 메일 인용 공개를 시작으로 PyCon까지 엄청난 파장을 일으키고 있는 IronPython, 올해 OSCON에서 100달러 내기를 겨루게 되는 Parrot Pie-Thon, 혼자 만들었다고는 믿기지가 않는 8bit CPU를 위한 pymite 등등 정말 재미있는 파이썬 구현들이 많아지고 있습니다. +_+

그러는 와중 이제는, esoteric 계열 언어까지 하나 등장했습니다. 사실 완전히 escoteric 계열은 아니고 그쪽에서 놀던 사람들이 -.-;; 이름은 Prothon, Prototype Python을 줄여쓴 것이라는군요. 특징은 그동안 파이썬을 조금만 쓴 사람이면 다 불평하는, 완전한 쓰레드 지원 (fine-grained locking, object locking)이 들어갔고, lua 5에서도 도입하고 요즘 한창 인기인 스택리스 시스템으로 구현되었으며, 가비지 콜렉션이 CPython처럼 부가적인 마크-앤-스윕 이 아니라 바닥부터 마크-앤-스윕 으로 쓰레드마다 돌아갈 수 있도록 되어있다고 합니다. 사실 pymite에서도 그랬고, 파이썬을 새로 만들겠다 하는 사람들이 다 쓰는 특성이 아닐까 합니다. 크흐;

또한, Prototype Python 이름에서 풍기듯, Prototype-based Language를 표방하고 있다는 점에서 클래스 기반인 Python과는 좀 다르다고 하기는 하는데, prototype-based랑 class-based의 차이가 뭔지 아직 잘 모르겠습니다. -ㅇ-; (전에 들었는데 까먹었다 ㅠ.ㅠ) 그리고, 인덴트 제한이라던지, int형이 이터러블하고, /* */ 주석이 추가되고 등등 엄청나게 많은 문법 수정이 가해졌는데, 이건 참신한 시도이긴 하군요. 실험적인 독자 문법이 시장에 나와서 실제 사용자들의 반응을 볼 수 있는 좋은 기회인 듯 합니다.

그리고 독특한 특징 하나는 포터빌러티 레이어를 위해서 아파치의 APR을 썼다는 것입니다. 기존에 공개된 오픈소스 포터빌러티 레이어라면 glib이나 모질라의 nspr같은 것도 있긴 하겠는데 아무래도 라이선스 문제상 apr이 좋긴 하겠지요.. 그런데 apr은 영 거시기 한 것이 약간 거부감이 들기는 합니다. ;;

아직 프리알파 상태라서 지원 모듈이 극소수만 있다고 하는군요. 있다가 퇴근하고 해봐야겠습니다.

• Prothon 홈페이지: http://prothon.org/

전의 블로그에서 언급한 기사가 OSS에 등록이 됐습니다. 흐흐 출판된지 1달도 안 됐는데, 막 올려도 되나 모르겠네요. 뭐 원고료도 없는 것이니 딱히 저작권 주장은 안 하겠지만서도 –;

http://developer.oss.or.kr/developissue/view.html?num=18&page=1

요즘 뜨는 언어들은 언급을 안 하고, 옛날 언어들만 언급함으로써 독자의 시야를 약간 가려서 설득시키려고 시도했습니다. (…)

아 근데 뭐 생각해보면 사실 파이썬이 젤 좋지 않아요? =3 =33 (ㅠ.ㅠ)