OpenLook

• 파이썬 2.3.4 RC 1이 릴리스되었습니다. 2.3.4가 정식으로 나오기 전 마지막 릴리스 후보이며, 2.3.3에서의 주요 변경사항은 대부분 버그 수정에 관한 것입니다. 제가 고친 건 전체 22개 중에 3개군요. ^^;; 정식 릴리스는 5월 20일쯤에 나올 예정이라고 합니다. 포트는 지금 퇴행 검사를 모두 통과하는 것을 확인했기 때문에, 릴리스된 당일 바로 갱신할 예정입니다.

• 서지원님께서 이제 훈련을 마치고 돌아오셨기 때문에, 제너레이터 익스프레션이 활발하게 진행되고 있는데요. 원래 5월 첫째주에 CVS에 들어갈 계획이었지만, 아직도 얼리-바인딩, 레이트-바인딩, 거의-레이트-바인딩 세가지 갖고 국론(?)의 분열이 엄청나게 심했기 때문에, 순조롭지만은 않은 상황입니다. 현재 저와 Raymond의 리뷰가 끝났고, 바이트코드 컴파일러 전문가인 Jeremy에게 리뷰 요청이 들어갔는데, 그 후에 아마 들어갈 수 있을 것으로 보입니다. Guido가 강력하게 만표를 행사하고 있는 의견은 거의-레이트-바인딩 인데, print >> None 의 동작에서 의 선택처럼 제일 헷갈리고 초보자들을 놀라게 만드는 선택이기는 하지만, 우선은 많은 경우 편리하게 사용할 수 있고, 자세한 동작을 신경 써야 할 정도의 코드면 심플 제너레이터로 풀어서 쓰라고 주장하고 있습니다.

• devel/decompyle 이 2.3용으로 부활. 한참 2.2용으로 남아있었던 decompyle을 어느 의욕적인 해커가 2.3용으로 고쳤습니다. 원래 decompyle홈페이지에는 반영은 안 되어있는데, 고친 사람의 홈페이지에서 받을 수 있습니다.

• [재미있는 파이썬 무림 소식] -1/1000은 왜 -1인가: 최근 c.l.py에 “어느 오래된 C 프로그래머”가 -1/1000이 다른 C 컴파일러들에서는 0인데 왜 파이썬에서는 -1이냐는 것에 대해서 의문을 올렸습니다. 그에 대해, C의 역사하면 뭐 거의 말 그대로 호랑이 담배피던 시절부터 생생한 현장에 있었던 Tim이 i / j의 나머지값은 반드시 0보다 크거나 같고, j보다 작다는 조건을 만족하기 위해서는 몫이 -1이고, 나머지가 999으로 나오는 것이 맞다고 “파이썬 첫 릴리스를 하기 전”에 귀도와 합의 했다는 답장을 올렸습니다. 그에 대해 다시 다른 사람들이 C99에서는 -1로 나오는 것이 표준으로 채택되어있다고 반발하자, Tim은 역시나 특유의 산신령적인 어투로, C89에서는 어느 것을 쓸 지 정해져 있지 않았고, C99가 그런 “이상한(wrong)” 방법을 채택한 것은 포트란과의 호환성을 위한 것일 뿐, 아무 이유도 없다고 했습니다.

요즘 영 머리 안 쓰는 일만 했더니 머리가 굳어가는 기분이 들기 시작해서, 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은 아주 쓰기는 좋은데 코드가 유지보수가 불가능해보이고 국제화 문제가 있어서, 고민을 좀 더 해 봐야겠습니다~