lucy(perky):~/cvs/python/branches/p3yk% ./python
Python 3.0x (p3yk:43459, Mar 31 2006, 02:33:47)
[GCC 3.4.4 [FreeBSD] 20050518] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.
>>>

으흐흐.. 어제 귀도가 p3yk 브랜치 버전을 3.0으로 올렸습니다. 그래서 이제 3.0이 확~ 다가온 느낌이군요.. ^_^; (뭔가 꼭 학부 OS 첫 숙제들 같이 버전 고쳐서 컴파일해오기 한 것 같은 기분도 약간 -O-)

아직 텔레파시는 지원 안 합니다. :-)

어제 릴리스된 파이썬 2.4.3으로 lang/python 포트를 업데이트 했습니다. 이번에는 얼마 전에 lang/python-devel 포트에서 시험적으로 적용했던 pkg-plist 줄여쓰기를 메인 포트에서도 한 번 적용해 봤습니다. 원래 py, pyc, pyo를 모두 pkg-plist에 적어 두고 있었는데, 용량이 너무 커져서 파이썬 포트들만 모두 합쳐도 이제 1MiB가 넘어가는 판국이 되어서 pyc와 pyo를 빼고 awk로 중간에 처리를 하도록 해버렸더니 60KiB정도가 줄었습니다. :) 그리고, NO_NIS는 있으면서도 PORTMAP은 안 끈 시스템에서 설치하다가 파일이 없다고 에러나는 것도 rpcgen 대신 ypcat을 체크하도록 해서 고쳤습니다.

파이썬 2.4.3은 아주 마이너한 버그 패치들만 들어가 있기 때문에, 기능적으로는 특별히 볼 만한 것은 없지만, Coverity와 refleak check, buildbot 등 파이썬 개발팀에서 최근에 사용하기 시작한 완성도 높이기 덕택에, 자잘한 버그들이 정말 많이 수정되었습니다. (예를 들어 PyObject_Unicode(NULL) 하면 세그폴트 나버리는 문제라던지..) 완성도 관련이나 릴리스 자동화, 막판의 버그 픽스와 하위 호환성의 충돌과 관련해서 좀 더 깊숙히 할 얘기가 있는데 2.4.3 릴리스와 관련된 뒷얘기들은 다음 기회에 다시 자세히~

그나저나, 지금 확인해 보니 아직 넷비, 우분투, 젠투, 데비안, 페도라에는 2.4.3이 안 들어간 걸 봐서는 이번엔 프비가 대략 1등? ^_^;; =3=33 (시험 전날 공부는 안 하고 이런거나 --;;)

파이썬을 파이썬으로 주로 구현하는 야심찬 프로젝트인 PyPy 프로젝트는 뭔가 계기가 되는 굵직한 작업들이 주로 개발자들이 오프라인에서 모여서 스프린트를 하면 뭉터기로 해결이 되는 특징이 있습니다. 무협 영화에 보면 자주 나오는, 숨어있던 고수들이 어느날 갑자기 여기 저기서 흘러들어와서는 중원의 잡배들을 물리치고, 휙하고 사라지는.. 마치 그런 장면! (.. 괜히 흥분;;) 요즘은 우리나라의 서상현씨와 서지원씨도 참여하고 있어서 무척 흥미로운 프로젝트이지요.

그런데, PyPy 스프린트는 지금까지 거의 유럽에서 하고 가끔 미국에서도 했었는데, 이번에 처음으로 엉뚱하게 도쿄의 "아키하바라"에서 하기로 했다고 한다뇨~ 역시나 일본에서 하는 것이라 지난번 아시아 코드페스트에서 굉장한 지원을 해 주었던 FSIJ (Free Software Initiatives in Japan)에서 지원 해준다뇨~ 일본에 사는 파이썬 해커들 뿐만 아니라 많은 수의 유럽 해커들까지도 지원을 받아서 참가하는 것 같다뇽~ (;;)

게다가 이번 스프린트 주제 1번이 Squeak VM 백엔드에다가 PyPy를 올린다고 하니.. 특히 스퀵이 강세인 일본에서 많은 해커들이 활발히 참여할 것 같아서 무척 재미있을 것 같습니다. :) 아 역시 옆에 있는 나라 사람으로써 우리나라에서도 한 번 했으면 싶지만, FSIJ처럼 돈 많이 쓰는 곳이 없어서 약간 아쉽네요. ^_^;

어제 Vim 개발자 Bram Moolenar가 구글에서 일하게 되었다고 발표하였습니다. 물론 업무 중에 Vim 개발을 일부분 할 수 있도록 했다는데.. 무섭게 오픈소스 인력들을 빨아들이고 있는 구글이 독립 오픈소스 개발자들을 과연 몇 명이나 남겨놓을지 모르겠군요. -O-

Vim은 원래 우간다 어린이들을 도와주세요! 를 하고 있었지만, Bram이 모든 시간을 Vim 개발에 쓰면서 쉬는 동안에는 Bram의 생활비 지원으로 스폰서십이 바뀌었다가, 다시 Bram이 구글로 들어가고 나서부터는 우간다의 키발레 어린이를 돕는 것으로 원래대로 돌아간다고 합니다.

Vim 7에는 FreeBSD에서 EUC 환경에서 문서 끝을 다 깨먹는 버그가 수정되어 있으니 이제 편하게 살 수 있을 것 같아서 기대가 됩니다. :-) 우간다 어린이들을 도와줘야겠네요;;

이번에는 podcast 맛보기용으로 녹음을 한 번 해봤습니다. -O-; iTunes에 등록하실 때는 RSS URL로 http://openlook.org/blog/rss_itunes_xml 를 등록해 주세용.

아하하. 완전 어색하지만 예쁘게 봐 주세요.
==>> 파이썬 2.5 미리보기 6편: C API 청소 (아마도 처음이자 마지막회 -O-)

파이썬 2.5 미리보기 6편: C API 청소 (녹음 내용의 요약)

파이썬 2.5에서는 C API 청소가 약간 있었습니다. 그동안 문제로 지적되어 왔었던 const가 지정되지 않은 API 인터페이스의 문제들과, 크기를 지정하는 타입으로 int에서 Py_ssize_t로 바뀐 것이 대표적입니다.

const 문제는 PyString_FromString 같은 함수들이 문자열을 char *타입으로 받는데, const char*이 아니기 때문에, 일반적인 문자열 상수를 막 던지려면 경고를 피하려고 캐스팅을 해야하는 문제가 있었습니다. 물론 아예 그냥 상수로 선언을 안 하면 data 영역으로 떠서 메모리에 올라올 때 낭비도 있고요.. 그래서 이번에 const가 쫙 달려서 이제 깔끔하게 쓸 수 있게 되었습니다.

그리고, 그동안 크기를 지정하는 타입으로 int를 사용해 왔었는데, 그 때문에 문자열이나 리스트의 길이가 2^31자/개 까지로 제한되어 왔습니다. 이게 64비트 플랫폼에 가면서 문제가 됐는데, 따라서 플랫폼에 맞는 크기 지정 타입으로 내부적으로 Py_ssize_t를 선언해서 쓰기 시작하였습니다. 덕분에 대부분의 타입들이 64비트의 주소 영역을 충분히 활용하게 되었구요~

그런데, 하나 문제가 생겼습니다. API에서 주소 크기가 문제가 되는 경우, 즉 PyArg_ParseTuple 같이 가변인자를 동적으로 읽어오는 경우에 64비트가 올 자리에 32비트가 오고 그러면 포인터가 막 쭉쭉 밀려서 세그폴트가 나게 됩니다. 이 문제를 해결하기 위해서 그냥 디폴트로는 옛날처럼 int 타입하고 최대한 호환되게 남겨두고, PY_SSIZE_T_CLEAN 이라는 매크로를 Python.h가 포함되기 전에 정의가 되어 있으면 z# 같은 포맷까지도 모두 Py_ssize_t를 사용하도록 하였습니다.

파이썬 C API에서 가장 노가다성이 짙어서 과연 얼마나 심심해야 이런 것 할 시간이 날까 하고 생각하고 있었던 청소가 모두 끝난 것이라 무척 상쾌한 릴리스가 될 것 같습니다. :)

오랜만에 FreeBSD 관련해서 뭔가를 쓰는군요. ^.^ 지금 열심히 릴리스 엔지니어링 막바지 작업이 진행되고 있는 FreeBSD 6.1에 관심이 많으실 듯 합니다. 유명무실했던 5.x대 릴리스를 딪고 일어서서 이제 본격적으로 안정버전 대열로 들어갈 6.1은 FreeBSD의 역사에서 매우 중요한 역할을 할 듯 합니다.

오프라인 파이썬 서적 중 좋은 것을 추천하자면, 프로그래밍 입문자용으로는 당연히 《Python Programming for the Absolute Beginner》를 추천하겠지만, David Beazley의 책이 막강하게 지키고 있던 기존에 다른 언어를 쓰던 프로그래머들을 위한 것으로는 David Beazley책이 한물간 이후로는 적당한 것이 딱히 없었습니다.

1판에는 귀도가 추천사를 쓰기도 했던 Beazley의 《Python Essential Reference》는 굉장히 간결한 설명으로 이미 다른 언어에서 뿌리를 내리고 있는 사람들이 옆으로 곁가지 치는 식으로 파이썬을 배우기에는 정말 좋은 놈이었습니다. 그런데 파이썬 책들이 갖게되는 공통적인 문제점.. 파이썬 버전이 올라갈 때마다 문법이 계속 새로 나와서 옛날 버전 책을 사기가 굉장히 난감하다는 것 때문에, 2판이 2.1에 맞춰서 나오자 마자 2.2가 나와버린 이후로 역사의 뒤안길로 미뤄져 있었던 것이었습니다. 이번에 드디어 2.4용으로 업데이트가!

Types and Objects in Python이라는 챕터가 샘플로 올라와 있습니다. 보니까 드디어 isinstance도 다루고 있고, 부담없이 추천할 수 있게 되었네요. :) 그렇지만.. 이번에도 이 책의 운명은 참 불쌍합니다... 2.5가 곧 나올텐데.. ㅠ.ㅠ

(축구장에서 뉴캐슬 후보팀이 훈련하는 중에 감독이 훈련생 산티아고 뮤네즈를 부른다)
감독: 뮤네즈! 이리 와 봐!
산티아고: 네 감독님
감독: (멀리 있는 골대를 가리키며) 내가 뛰라고 하면 골대까지 최대한 빨리 달린다. 알겠나?
(산티아고가 골대로 달려가는 도중에 감독이 골대를 향해 공을 찬다. 공이 먼저 골대에 들어간다.)
감독: 다시 와
감독: 다시 뛰어!
(다시 산티아고가 달려가고 감독이 찬 공이 앞지른다.)
감독: 뭘 배웠나?
산티아고: 중앙선에서도 골을 넣을 수 있다는 건가요?
감독: 공이 사람보다 더 빠르다는 것.
감독: 우리는 패스한다. 알겠나? 우리는 팀이야. 원맨쇼가 아니라구. 셔츠 앞에 있는 이름이 등 뒤에 있는 이름보다 더 중요해, 알겠나?

오늘 《Goal》이라는 영화를 보다가 문득 생각이 나서.. :) 산티아고는 동네 축구에서 자기 실력이 워낙 뛰어나다보니 패스를 잘 하지 않는 습관이 있었는데 훈련 모습을 보고 있던 감독이 그것을 지적해주기 위해서 직접적으로 패스를 하라고 다그치지 않고 직접 느끼는 기회를 만들어주었습니다. 산티아고가 조금 더 똑똑했더라면, 바로 뭘 발견하게 하려 한 것인지 눈치를 챌 수 있었겠지만, 충분히 느낄 수 있는 여유를 준 다음에 설명을 해 주었기 때문에 산티아고는 아무래도 패스를 해야 한다는 것에 대해서는 잊을 수 없는 기억을 갖게 되었을 것입니다.

또한, "패스를 해야 한다."라고 말해 주었다면 느끼기 힘들거나 곧 까먹어버렸을 언제 패스를 해야하는가, 패스를 안 하면 어떻게 되는가, 패스할 기회를 어떻게 만드는가 등등 파생되는 지식들도 쉽게 생각할 수 있었을 것입니다.

대안언어축제와 생물정보학 S/W XP 세미나에서 창준형의 제안으로 같이 시도했던 여러가지 일들에서 정말 놀랍게도 참가하는 분들이 훨씬 열정적이고 능동적으로 참가하게 된 것에는, 신체의 극히 일부인 귀와 뇌로만 느낀 것이 아니라, 머리 끝부터 발 끝까지 함께 다 경험한 것이 큰 도움이 되지 않았나 하는 생각이 들었습니다.

예를 들어, 개발 프로세스 개선을 하면 더 적게 일하고도 좋은 결과가 나온다는 것을 위해 종이비행기 공장을 게임처럼 해 본 것이나, 개개인의 사소한 마음이 모여서 큰 차이를 보일 수 있다는 것을 느꼈던 날아가는 새 편대/수호천사놀이 같은 것은 굉장한 효과를 느낄 수 있었습니다. 그 뿐만 아니라, 스케줄 안에서도 다음 단계에서 나오는 개념들이 자연스럽게 앞에서 삽질을 하면서 도출될 수도 있도록 한 것은 마치 자신이 발명했다는 느낌까지 들 수 있다는 점에서 어느 교육과정에서도 반드시 고려해야 할 사항이 아닌가 생각이 듭니다.

요즘 학교에 다니면서 수업들을 들을 때 얼마 전에 읽었던 《미국 최고의 교수들은 어떻게 가르치는가》의 교수들이 가르치는 기법들을 생각하며, 그 교수들이 가르친다고 상상하면서 최대한 그 사람들에게 배우는 효과를 누려보려고 노력해 보고 있습니다. 그래서, 괜히 앞에서 설명하는 것을 들으면서 다음에 나올 내용 같은 것을 상상해보면서 딱 맞히면 괜히 뿌듯하기도 하고.. 흐흐.. 대부분의 과목들이 실질적으로는 시간이 부족해서 비판적인 수업을 전혀 하고 있지 않지만, 속으로 수업 중에 의아했던 부분과 갑자기 등장하는 개념들 같은 것들을 비판해보면서 종이에 적어 뒀다가, 다음에 책을 찬찬히 보면서 그에 대한 반론도 혼자서 해보고.. (요즘은 숙제에 치여서, 그럴 여유는 잘 없지만;;)

그래서, 또 하나 전에 학교 갔다가 집에 오면서 생각해 본 것이, 컴퓨터과학에서 "자료구조"와 "프로그래밍언어구조론"같은 과목들은 비교적 쉽게 "학생들이 늦게 태어난 바람에, 좀 더 늦게 발견을 했을 뿐" 이라는 감정을 느낄 수 있게 발견으로 가득 찬 수업을 할 수 있지 않을까 생각을 해 봤습니다. 소팅을 배울 때는 카드를 정렬할 때 규칙을 세우라고 하고서는 계속 개선 방법을 만들어 본다던지.. 트리를 배울 때나 amortized analysis 같은 것도 삽질을 해 보면서 발견을 쉽게 할 수 있도록 (그리고 꼭 경험해야 하는 삽질은 고루 거칠 수 있도록 함정을..) 도와주면 좀 더 재미있지 않을까 생각을 해 봤습니다. 흐흐..

에.. 뭐 그냥.. 영화보다가 딴 쪽으로 공상을 너무 많이 했군요. -O- 요새 TV를 봐도 온통 "맞아 맞아~" 하면서 끄덕거리고.. 길거리의 엉뚱한 포스터를 봐도 "맞아 맞아~" 하면서 끄덕거리고.. 귀가 얇아진건지 원.. 으흐흐~

이전 연재 보기

• 1. with 절
• 2. Arena-freeing obmalloc
• 3. incremental codecs
• 4. ctypes

오늘은 파이썬 2.5에서 가장 논란이 될 만한 부분인 PEP-308 Conditional Expressions에 대해 알아보겠습니다.

C의 ? : 이른바 삼항연산자라고 부르는 그 놈은 C에서 파이썬으로 넘어오는 개발자들이 항상 목말라하는 그런 것이었습니다. 그래서, 궁한대로

1) a == b and 1 or 0
2) [0, 1][a == b]
3) (a == b and [1] or [0])[0]
4) {True: 1, False: 0}[a == b]

이 문제 해결을 위한 여러 사용자들의 꾸준한 요청으로 귀도가 드디어 투표를 하기로 결심해서, 2003년에 투표를 해서 결정이 되긴 했지만, 여러 분파로 나뉘어서 그 후에도 좁혀지지 않는 의견차로 인해서 실행이 될 기미가 보이지 않았습니다. 그래서 결국 1000000표를 행사하는 귀도가 모든 사람이 상상도 못했던 희한한 문법을 들고 나와서 그걸로 결정해 버렸습니다. (이런 일은 print >> None 때도 다들 황당했었지요.. ;;)

결정 문법: X if COND else Y

X가 맨 앞에 나오지만 X가 먼저 해석되지도 않을 뿐더러, COND가 중간에 숨겨지고, X와 Y가 떨어져있는 등 귀도 외에는 좋아하는 사람이 거의 없는 듯 했지만, 어쨌거나 이 문법으로 결정이 되었습니다. 그 문제는 구현까지 완료돼서 들어오고 나서 더욱 더 강조가 되게 되었는데,

text = data if logging else ''

이렇게 쓰면 다른 언어들의 if, else 문법들의 영향으로 다음 중 어느 것으로 해석되는지가 굉장히 헷갈립니다.

1) (text = data) if logging else ''
2) text = (data if logging else '')

물론, 파이썬에서는 1번이 기본 구조로 불가능하기 때문에 2번이 정답이기는 하지만, 다음과 같이 꼭 띄어써야 하는 부분이 아니면 안 띄어쓰는 (약간은 ㅂㅌ스러운 ㅎㅎ;) 코딩 컨벤션을 쓰는 사람이라면 훨씬 더 난감해집니다.

text=data if logging else ''

으흐흐.. 하여간, 이 문법이 과연 파이썬 3.0까지 살아남을 수 있을지 두고 봐야겠습니다. "print >> file" 처럼 처음에는 다들 굉장히 싫어했지만, 결국에는 다들 익숙해져버리는 쪽으로 될 지도 모르겠고요..

그동안 오픈소스 프로젝트 몇 개에서 활동을 하면서 느꼈던 생존 전략을 몇가지 올려 봅니다. 물론, 이런 것들은 절대적인 것은 아니고, 상황에 따라서 다를 수도 있지만 그런 상황도 있을 수 있구나 하고 나중에 패치를 제출하실 때 참고가 되실까 해서 몇 가지 적어 봅니다.

우선은 눈치를 잘 보고 관례를 따르자.

어느 커뮤니티던 각자 고유의 성질이 있습니다. 어떤 곳은 생각보다 엄청나게 보수적인 곳도 있고, 어떤 곳은 새로운 패치가 올라오면 열렬히 좋아하면서 달려들어서 오히려 부담되는 곳도 있고.. 어떤 곳은 모르는 사람이 글을 올리면 반감을 보이는 곳도 있고.. 주제에 약간 벗어나는 글(OT)에 대해 어떻게 상대하는지도 각각의 커뮤니티에 따라서 많은 차이를 보입니다.

대부분의 커뮤니티는 각각의 관례가 있는데 그 관례를 외부인이 쉽게 눈치채지 못해서 처음에 실수하는 경우도 많이 있습니다. 예를 들어, 어떤 곳은 패치를 버그트래커에 올리는 것을 좋아하는 곳도 있고, 또 다른 어떤 곳은 개발자에게 직접 사적으로 보내는 것을 좋아하는 경우도 있으며 그 구분의 정도도 각각 다른 편입니다. 첫 패치가 문서나 테스트를 포함해야 하는지, 어느 정도의 패치는 미리 작업 전에 아이디어를 올려야할지 등 많은 차이가 있기 때문에, 관심있는 곳은 어느 정도 익숙해지는 편이 참여하기가 쉽습니다. 물론, 참여할 때 아는 사람이 원래 참여하고 있었다면 그 사람에게 조언을 구하는 것도 좋습니다.

초반에는 묻어가기를 잘 하자

입지가 어느 정도 굳어지기 전까지는 "묻어가기"가 아주 쉬운 참여법입니다. 각 커뮤니티들은 주제가 아무리 넓어도, 대략적인 흐름이 있어서 유행하는 토픽이 몇개가 항상 떠 있기 마련입니다. 자신과 관련된 주제가 스물스물 올라올 때, 자기가 갖고 있던 생각이나 패치나 그런 것들을 괜시리 관련 지어서 같이 올려버리고 하면, 그냥 올리면 별 관심 없었을 사람들도 같은 쓰레드에 있다보니 덩달아 보고 해서 좋습니다. :) 같이 커밋되는 경우도 있고, 상대방들도 마침 관련 코드를 보고 있던 상황이면 아무래도 쉽다보니 같이 리뷰해 줄 확률도 올라갑니다.

한 박자 빠르게

각 커뮤니티에는 오랫동안 개발에 참여하던 개발자들이 직접 하기에는 따분하고 여유가 없는 일들이나, 새로운 아이디어가 있긴 한데 구현이 쉬울지 확신이 안 가는 경우가 생각보다 자주 발생합니다. 바로 이 경우가 터줏대감 개발자들과 친하게 지낼 수 있는 절호의 기회입니다. 그 때 잽싸게 패치를 만들어서 올려주면 패치 리뷰도 하고 하면서 좋은 기회가 많이 생기게 마련이고, 다른 사람들에게 이름 언급도 많이 돼서, 구글 히트도 올라가고 인지도도 올라갑니다. ^.^ 물론, 여기서 중요한 것은 잽싸게 패치를 만들 수 있느냐가 관건인데, 사실 저같은 경우에도 잽싸게 패치를 만들어야지 하고 마음을 먹어도 10번 시도하면 1번 정도만 끝까지 하고 나머지는 뭐가 문제인지 파악하고 대충 그냥 그렇구나 하고 중단합니다. 여러 번 시도하다보면 어쩌다 한 번은 땡잡아서 이른바 "low-hanging fruit"를 쉽게 따는 경우가 있습니다. :)

한 박자 느리게

중요한 일일수록 한 박자 느리게 할 필요도 있습니다. 기회를 잡을 때는 잽싸게 하면 되지만, 다른 경우에는 메일에 답장할 때도 써놓고 1~2시간 정도 놔두고 있다가 보내거나, 저장해 놓고 아무도 비슷한 글을 안 올린다 싶으면 올리면 좋은 경우가 많습니다. 1~2시간 정도 놔두면 다른 사람들이 답글을 올리는데, 훨씬 더 경력이 많고 뛰어난 사람들의 답글을 읽다보면 자기 글이 틀렸다고 생각이 드는 경우가 제법 있습니다. 아무래도, 계속 틀린 말을 하게되면, 자기 스스로도 위축되게 되고 다른 사람들한테도 이미지 저하가 제법 일어나서 패치를 리뷰해줄 때 협조를 얻기가 힘들어지고, 새로운 주장을 할 때도 동의를 얻기가 힘들어집니다.

첫인상이 중요하다

개인적인 첫인상도 물론 중요하긴 하지만, 오픈소스에서 가장 중요한 것은 코드의 첫인상입니다. 패치의 앞 몇 줄의 코드 품질이나 예시로 올린 글에 포함된 몇 줄의 예제 코드가 다른 사람들의 동의를 얻느냐 아니면 답글 하나도 안 달리고 아카이브의 한 줌의 비트로 묻히게 되느냐를 결정하게 됩니다. 따라서, 코드를 올릴 때는 반드시 프로젝트에서 쓰는 코딩 컨벤션을 지켰는지 꼼꼼하게 체크를 하고, 제공되는 테스트는 모두 확실히 돌리는 것이 좋습니다. 패치 하자 마자 바로 커밋만 하면 되는 상태까지 완벽하게 해서 패치를 제출했다면, 곧 커밋 권한을 받을 가능성이 매우 높아집니다. :)

변화는 조금씩

전통적인 구조의 회사에서 일하는 프로그래머들은 깜짝쇼를 좋아합니다. 뒷방에서 몰래 만들고 있다가, 데모 날짜 잡고 전직원 모아놓고 와~~ 하면서 짝짝짝 하면 물론 쇼하는 분위기도 나고 좋긴 하지만, 코드 통합의 관점에서는 최악의 경우입니다. 오픈소스 프로젝트들은 개발자들이 하위 호환성 유지에 쏟고 있을 여유가 많지 않기 때문에, 너무 많이 확 바꿔버리는 패치나 하위호환성을 완전히 깨버리는 패치를 올려버리면, 패치는 올라오자마자 팽당하는 사태를 맞게 됩니다. 패치는 최소한으로 분리를 해서 따로 따로 제출하는 것이 그 유명한 "divide and conquer"의 관점에서도 더 옳은 방법이며, 한꺼번에 패치를 많이 올리면 최근 메일 목록에서 확 도배를 하는 효과도 있기 때문에 강한 인상을 줄 수 있습니다. --; (그렇다고 일부러 패치를 몰아서 보낼 필요는 없습니다. =3)

공손한 사람이 되자

공손하게 말을 하면, 간혹 상대방의 역공을 받더라도 공격이 무디게 들어옵니다. 자신의 입지가 확고하지 않을 때에는 would, may, could , think 등.. 애매모호한 말을 총동원해서 애매한 해석이 가능하도록 여지를 남겨두는 것이 좋습니다. :) 물론, 익숙해지기 전까지는 Thank you for 뭐해줘서! 는 필수입니다. 항상 서로에게 감사하는 것이 오픈소스이지요 ;;;

그냥 재미로 하자

뭔가 목적을 두고 목적에 대한 과정으로 쓰게되면, 곧 그 과정이 싫증이 나기에 마련입니다. 헌신적인 마음이나 목적에 의한 노력은 일시적으로는 프로젝트에 힘을 쏟을 수 있게 하지만, 곧 시들게 마련입니다. 오픈소스 프로젝트들은 보통 아주 장기간의 릴리스 엔지니어링과 커뮤니티의 피드백 수렴 과정 같은 것이 있기 때문에, 단기간에 끝낼 수 있는 경우가 드뭅니다. 따라서, 장기간 동안에도 지치지 않게, 그냥 여유 있는 시간에 무리하지 않고 재미로 스트레스는 최대한 피하면서 참가하는 것이 좋습니다. 스트레스를 피해 잠시 도망가 있으면 다른 사람들이 해 줍니다. ^^; (자기에게 스트레스를 주는 일이라도 다른 사람들은 재미있는 일인 경우가 많습니다.)

상대방의 입장에서도 생각해 보자

처음 오픈소스 프로젝트에 참여할 때에는, 패치를 제출했을 때 금방 응답이 오지 않으면 굉장히 조바심이 나기에 마련입니다. 저도 처음 패치를 내고서 5분 안에 답장이 안 와서, 무시됐나 하고 생각했는데.. 결국은 첫 패치가 5달만에 답장이 와서 적용이 됐습니다. -O-

프로젝트에 참여하고 있는 다른 사람들도 대부분은 바쁜 사람들이고 자신과 관련이 없다 싶은 것에는 관심이 전혀 안 생길 수도 있습니다. 그래서 더 재미있겠다 싶은 것을 먼저 처리해 주거나 관심을 보이는 것도 그 사람 입장에서는 어찌보면 당연한 일입니다. 끈기를 가지고 여유있게 기다린다거나 바람을 잡는다거나 뭐 몇가지 선택지가 있는데 더 능동적인 방안으로는 기존에 영향력이 있다고 생각되는 사람들의 관심사를 파악한 다음에 그 관심사와 겹치는 것에 대한 작업을 어느 정도 해서 올려서, 피드백을 하면서 친해진 다음에 부탁한다거나, 다른 사람들이 관심을 가질 수 있게 화려한 수식어나 표준 참조를 마구 갖다 끌어붙이는 등의 동기 부여가 필요합니다. 부가적인 다른 패치를 올린 다음에 그 패치가 앞 패치에 의존성을 갖도록 해버리는 것도 하나의 테크닉이죠. :)

그 외의 일일이 언급하기 힘든 여러가지 것들..

오픈소스 커뮤니티의 다른 조직에 대한 가장 큰 특징은

• 대부분의 사람들이 온라인에서 만나서 원거리에서 얘기한다
• 여러 참여자들은 각기 다 다른 시간대에서 생활하며, 여유시간이 모두 다르다
• 대부분의 코드는 집합적 소유권(collective ownership)의 특성이 매우 강하지만, 나름대로 암묵적인 소유권이 있는 경우도 많다
• 대부분의 커뮤니케이션이 전화나 오프라인의 동기식 통신이 아니라 비동기식 통신이므로 답변의 순서도 뒤죽박죽이고 답변이 늦거나 아예 없을 수도 있다
• 일반적인 회사 조직은 피라미드형 구조로 위계 구조가 단순화 되어 있는 편이지만, 오픈소스 커뮤니티들은 커뮤니케이션에 있어서는 굉장히 평면적이고 수백~수천명까지 한꺼번에 참여를 하지만, 안 보이는 인지도와 협력관계, 친분관계 등이 많은 작용을 한다
• 재미와 흥미가 동기를 부여하는 경우가 매우 많다. 따라서, 지루하고 힘든 일은 처리되는데 시간이 굉장히 오래 걸린다

선 코딩 후 테스트식 개발을 할 때에는 커버리지 분석 도구가 꼭 필요합니다. 상용 커버리지 분석 도구 중에서는 파이썬 코드도 예쁘게 분석 결과를 보여주는 것이 있었는데, 아직 오픈소스 도구 중에서는 딱히 마땅한 게 없었는데요, 드디어 하나 제대로 예쁜게 나왔군요. trace2html! 출력 예시를 보면 trac과 함께 파이썬기반 프로젝트들이 꼭 설치해야 할 프로그램이 하나 늘었네요~ :) (trac 플러그인으로 들어가길!)

비주얼 스튜디오나 델파이/C++빌더 같은 윈도우 기반 IDE들에 익숙한 개발자들이 쓸만한 IDE도 하나 발견했는데, PyScripter 상당히 예쁘군요. 아무래도 델파이 개발자들 눈에 맞춰서 만든 컴포넌트들을 그냥 그대로 갖고 와서 쓰다보니 그렇게 된듯~ 단, 델파이로 되어 있기 때문에 IDE를 고친다거나 포팅한다거나 하는 것은 굉장히 어렵겠습니다. 스크린샷

요새 파이썬 2.5 릴리스 엔지니어링 시작이 임박하면서 여러가지 새로운 소식이 나오고 있어서 몇가지 전해 드립니다. :)

• 파이썬 홈페이지 디자인 변경: 아직 완전히 끝난 것은 아니지만 전체적인 디자인이 회사스럽게 바뀌었습니다. 아무래도 투박한 오픈소스 프로젝트형 디자인에 익숙하지 않은 경영진들에게도 신뢰감을 줄 수 있겠죠.. :) 보면서 하나 눈여겨 볼 수 있는 부분은 화면 아랫쪽의 구글광고입니다. 일반적인 구글 애드센스가 아니라, 구글 애드센스에서 곧 도입할 예정인 탭 광고를 테스트 중이라고 합니다. 한동안 저 자리에 MS Visual Basic 광고가 나왔던 적이.. 흐흐;
• 파이썬 3000 프로젝트 시작: 귀도가 드디어 svn 저장고에 파이썬 30000 브랜치를 만들었습니다. 이름이 py3k가 아니라 p3yk입니다. -O-;;; 아직은 활발한 개발이 시작된 것은 아니고, 구글에서 50% 자유시간의 대부분을 파이썬 3000에 쓴다고 하니까 기대가 되는군요~ 지금 현재로써는 with문 future만 제거된 것이 들어가 있습니다.
• PSF 블로그 개설: 파이썬 소프트웨어 재단의 블로그가 개설되었습니다. 재단에서 행사 조직과 관련해서 많은 일을 하고 있는 amk가 주로 쓰게 될 것 같군요. 지금 현재는 PyCon관련 설문 같은 것이 올라와 있습니다. :)
• 파이썬 2.5 릴리스 일정: 파이썬 2.5 릴리스 코디네이터가 Neal Norwitz로 결정되었고, 4월 1일부터 알파 1 릴리스를 시작해서, 8월 19일에 최종 릴리스를 하는 것으로 일정이 잡혔습니다. 2.4에 비해서 굉장히 많은 것이 바뀌기 때문에, 아주 설레입니다. ^.^
• Coverity 체크: 최근에 스탠포드에서 나와서 별도의 회사가 된 Coverity에서 여러 오픈소스 프로젝트들의 static analysis 결과를 제공해주었습니다. perl쪽에서는 처음에 coverity에서 경고한 버그 수가 적다고 그걸 기사로 쓰는 곳까지 있었는데, 파이썬 개발자들이 재빠르게 대응해서 곧 펄의 1/2 이하로 줄여서 최저 1000라인 코드당 0.01개의 버그 경고로 줄였습니다. (최근 ctypes 임포트 이후에 30개 정도가 새로 들어와서 좀 늘었습니다;;)

오랜만에 한글 PuTTY 새버전을 릴리스 했습니다. 원래는 커서 패치를 업스트림하고서는 더 이상 안 건드리려고 했는데... 정치력 부족으로 아직 패치를 밀어넣지 못해서 -.-;; ㅠ.ㅠ

이번 릴리스의 변동점은.. 아무래도 새 버전이니까 기분이 좋은데.. 뭐가 바뀌었는지는 잘 모르겠네요 하하하.. -ㅇ- 궁금하신 분은 릴리스 노트를 보세요. +_+

그나저나 버전 올라갈 때마다 코드가 엄청 많이 바뀌어서, 매 버전마다 매번 새로운 방식을 연구해서 패치하는 게 무척 귀찮아서.. 얼른 정치력 연마를 좀 더 해야겠네요..

알림: 이 글은 이전 스크립트 자체에 대한 글이며, 이글루스나 다음 등 사이트 자체에 대한 어떠한 선호도 의도된 것이 아닙니다. 저는 둘 다 안 쓰기 때문에 별로 신경쓰지 않습니다. ^^

어느 분의 부탁으로 이글루스에서 다른 사이트로 블로그 이사를 하는 스크립트를 만들었습니다. ==> Blogyltransferase 1.0 다운로드 (win32용), 소스 코드 및 타 플랫폼 (svn)

두 번째로 만들어 본 wxPython 프로그램인데, 이제 그런대로 익숙해 져서 크게 불편하지 않네요. 하하하.. (그새 배신을;;) 이글루스의 기본 스킨이 워낙 잘 되어 있어서 스크린 스크래핑 하기에 굉장히 좋았습니다. BeautifulSoup의 특성을 만끽할 수 있는 최고의 실험 재료가 아닐까 하네요. +_+

앞으로 다른 API도 적당한 것이 있다면 다음 블로그 API외에 다른 것도 지원할 수도 있겠습니다. (MetaWeblogAPI같은 것은 코멘트나 트랙백을 옮길 방법이 마땅찮더군요.)

사용 방법은 http://xxxx.egloos.com/ 의 xxxx를 블로그 이름에 넣고, 다음 블로그로 옮기는 경우에는 다음 블로그를 먼저 개설하고, 다음넷 사용자 이름과 비밀번호를 입력하고 "전송 시작!"을 누르면 됩니다.

이사가 잘 되었으면 이 글에 트랙백을 보내주세요. :)

• 지난 달, 자바스크립트의 아버지인 Brendan이 파이썬의 이터레이터와 제너레이터를 자바스크립트에 표준에 넣기 위해 ECMA 워크그룹에서 논의 하겠다고 하였습니다.
• Athena라는 파이썬용 양방향 AJAX라이브러리에서는 파이썬 예외에 자바스크립트측 콜 스택과 소스코드까지 모두 넘어오도록 지원하기 시작했습니다.

>>> import ctypes
>>> libc = ctypes.cdll.c
>>> libc.getosreldate()
600104
>>> buf = ctypes.c_buffer(30)
>>> libc.memset.restype = None
>>> libc.memset(buf, 5, 30)
>>> buf.raw
'\x05\x05\x05\x05\x05\x05\x05\x05...'
>>> libc.memset(buf, 45, 30)
>>> buf.raw
'------------------------------'
>>> ctypes.pythonapi.PyString_FromString.restype = ctypes.py_object
>>> ctypes.pythonapi.PyString_FromString(buf)
'------------------------------\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t'

드디어 이전에 작업했던 대로 파이썬 2.5에 ctypes가 들어왔습니다. :-)

벌써부터 uuid 모듈이나 앞으로 들어올 표준모듈에서도 ctypes를 활용할 것 같은 분위기입니다. platform 모듈에서도 쓸 수 있을 것 같고요~

일본 파이썬 유저그룹에서 4월 8일에 Python Workshop the Edge 2006을 개최한다고 합니다. 일본그룹에서는 2005년부터 대략 3~4개월에 한번씩 워크샵을 주기적으로 개최하고 있는데, 하루 저녁동안 하는 것이기 때문에, 왠지 한국에서 워크샵 그러면 여러 날 할 것 같지만 그런 규모는 아니고, 좀 큰 규모의 스터디 그룹 정도로 보입니다.

일본의 파이썬 워크샵은 장소가 아주 독특한데, "마이크로소프트 본사"랍니다. 물론 미국의 본사는 아니고, 일본 마이크로소프트의 본사겠지만, 전통적으로 이런 행사를 지원하는 아스키 출판사 같은 곳이 아니라 마이크로소프트가 지원하는 이유는 도대체 무엇일까! --- 바로 이번 워크샵의 마지막 세션에 힌트가 있습니다. 일본 MS 직원이 직접 IronPython에 대해 발표하는 것입니다! IronPython을 미국 본사의 CLR 팀에서 Jim 혼자서 삽질을 하는 것이 아니라, 일본에서도 전략적으로 의미를 두고 있고 커뮤니티 지원을 한다는 점이 상당히 인상적입니다. (참고: IronPython은 마이크로소프트에서 BSD 라이선스로 배포하는 .NET기반 파이썬 구현입니다.)

그 외의 다른 세션들로는 kizasi라는 요새 일본에서 유명한 블로그 통합 사이트의 개발자가 파이썬으로 사이트를 구축한 사례에 대해서 발표하고, 튜토리얼 세션 하나, SkypeJapan에서 Skype 파이썬 API에 대한 발표를 합니다. 그리고, 요새 파이썬 관련 모임이라면 어디서나 항상 나오는 웹 프레임워크들 Django, TurboGears과 비교적 덜 알려진 web.py에 대해 패널 토론이 있다고 합니다.

한국에서도 언젠가는 이렇게 정기적인 워크샵을~

파이썬 2.5의 또 다른 주요 변화로 소개해 드릴 만한 것으로 incremental codec이 있습니다. 파이썬 유니코드 코덱의 기존 스펙에 대한 확장인데, 논의되는 과정 중에 여러가지 난관이 있었습니다. 확장이 쉬운 디자인이 어떤 것인가, 확장이 어려운 디자인을 택했을 때 나중에 확장을 어떻게 할 것인가에 대한 좋은 사례가 될 듯 합니다.

파이썬 2.0에서 처음 들어온 PEP-100 유니코드 통합에서는 4가지 코덱 방식을 정의하고 있습니다. 인코더, 디코더, 스트림 인코더, 스트림 디코더 입니다. 인코더와 디코더는 상태가 없는 (stateless) 단순 문자열 변환을 담당하고, 스트림 인코더와 스트림 디코더는 파일같은 스트림들에 대해서 상태가 있는 (stateful) 변환을 담당합니다.

얼핏 보면 상태가 있는 것도 있고, 없는 것도 있으니 괜찮은 디자인이 아닌가 하고 생각을 할 수 있는데, 파이썬 2.0이 릴리스 되고 나서, 그 이후에 JapaneseCodecs나 KoreanCodecs가 나오면서 문제가 발견되게 됩니다. 바로, 상태가 있는 문자열 변환을 할 수가 없다는 것입니다. 상태가 있는 변환을 하기 위해서는 스트림을 거쳐야하기 때문에, 엉뚱하게 계속 StringIO같은 것을 끼고 들어가야 하게 되어서, 번거롭기도 하고 느리기도 하고 아주 기분 나쁜 상황이 되어 버립니다. 게다가, 스트림은 끝이 단 하나만 존재하기 때문에, 현재 버퍼에 있는 미완성 부분을 완성하려고 파일 끝으로 표시해 버리면 더 이상 쓸 수도 없고 상태도 잃어버리는 문제도 있었습니다.

여기서 알 수 있는 디자인의 교훈은, 다른 언어에 있는 걸 무작정 따라하기 보다는, 해당 도메인에서 할 수 있는 작업들을 나열한 다음에, 각 작업들이 공통으로 가지는 최소한의 요소들을 뽑아서 그것들로 다른 작업들을 구성해 보면 좋겠다는 생각입니다. 간혹 어떤 라이브러리를 쓰다 보면, 한 함수의 극히 부분적인 기능이 필요한데, 더 작은 함수가 없어서 결국은 함수의 쓸데없는 다른 부분까지도 모두 에뮬레이트 해야 하는 경우가 있습니다. 그럴 때는 답답하고 억울해서 산에 가서 임금님 귀는~~ 이라도 하고 싶은 경험을 할 때가 있는데, 그 때의 경험을 마음 깊이 새겨서 그런 라이브러리를 안 만들도록 해야겠네요. :)

(얘기가 딴 데로 빠져서 다시 원래대로 오자면~) 그래서, 그동안 파이썬에서 여러모로 문제가 많았던 UTF-8 스트림 디코딩이 결국은 내부적인 상태 제어 함수를 만들어서 해결이 되었고, 애플리케이션들도 쉽게 이런 것을 쓸 수 있게 유니코드 스펙을 확장해서 기존의 4개에 2개를 더해 incremental decoder, incremental encoder가 추가되었습니다.

그런데 여기서 발생하는 또 하나의 디자인 문제! 코덱을 찾아 주는 codecs.lookup라는 함수는 위에서 언급한 4개를 tuple로 리턴해 주는 방식으로 되어 있다는 것! 그래서 결국은 이번에 새로 추가된 2개를 더하면 tuple의 크기가 바뀌어서 사용자 코드들이 하위호환성이 없어진다는 치명적인 문제가 생깁니다. codecs.lookup을 왜 public API로 공개해서 이런 문제를 만드냐~ 하고 이런 저런 서로 원망을 하다가 결국은 os.stat에서 쓴 트릭으로 처리가 되었습니다. 즉, 객체를 따로 하나 만들어서(codecs.CodecInfo) tuple 쓰듯이 접근하면 옛날처럼 4개를 돌려주고, 하위 속성을 접근하면 이름으로도 접근할 수 있게 하는 것입니다. 예를 들어, c = codecs.lookup('cp949') 일 때, c[0]부터 c[3], len(c) 하면 옛날 tuple 쓰듯이 흉내를 내고, c.incrementalcodec 이나 c.encoder, c.streamwriter 같은 방법으로 새로운 API를 쓸 수 있게 하였습니다.

그래서, 어제 Walter가 작성한 기본 패치에 맞게 CJKCodecs 패치도 만들었는데, 이제 본격적으로 incremental codec을 쓰는 세션을 하나 보겠습니다. :)

>>> import codecs
>>> dec = codecs.lookup('cp949').incrementaldecoder() # cp949 상태있는 디코더를 만듦
>>> dec.decode('한글') # 그냥 상태 없는 디코딩이나 마찬가지
u'\ud55c\uae00'
>>> dec.decode('한글'[:3]) # 마지막 1바이트 빼고 넣음
u'\ud55c'
>>> dec.decode('글'[1:]) # 남은 1바이트를 마저 넣어서 완성
u'\uae00'
>>> dec.decode('한글'[:3]) # 다시 첫 3바이트를 넣음
u'\ud55c'
>>> dec.decode('', True) # 버퍼에 '글' 앞쪽 바이트가 있는 것을 flush
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'cp949' codec can't decode byte 0xb1 in position 0: incomplete multibyte sequence
>>> dec.reset() # 버퍼를 초기화
>>> dec.decode('', True) # 버퍼를 초기화했기 때문에 비어있음
u''

cp949는 사실 좀 밋밋하긴 한데, 살 떨리게 재미있는 ISO-2022로 한 번 해 보면..

>>> dec = codecs.getincrementaldecoder('iso2022-jp')()  # 이게 더 좋은 방법
>>> ESC = '\x1b'
>>> dec.decode(ESC+'(')  # G1 캐릭터셋 할당 시퀀스 앞부분
u''
>>> dec.decode('J~~')  # 0201로 할당
u'\u203e\u203e'
>>> dec.decode('J~~')  # 이제 앞의 J는 이스케이프가 아님
u'J\u203e\u203e'
>>> dec.decode(ESC+'$B$@')  # G1을 0208로 바꾸고 1글자
u'\u3060'
>>> dec.decode('$@$@$')  # G1에서 2글자 더 진행하고 반은 남김
u'\u3060\u3060'
>>> dec.decode('@'+ESC+'(BABC')  # 0208에서 마지막 완성하고 ascii에서 3글자
u'\u3060ABC'

처음에는 이런 것을 지원해 주기 위해서 incremental codec이 아니라 feed style codec이라는 것이 나왔었는데, 뭔가 부자연스러워 보이는 것이 관련있는 사람 대부분이 답장도 안 올리고 바쁜 척을 했었습니다. 그런데, 새롭게 incremental codec이 나오고 나니까 다들 훨씬 깔끔하다고 칭찬을! 으흐흐. 아무래도 문제 해결을 억지로 라도 한 번 해 보고 나면, 훨씬 더 좋은 다른 방법을 발견하기도 쉽다는 것도 있겠고.. 다른 사람들이 바쁜 척하는 것 같으면 잘 눈치를 채야 한다는 뭔가가... -o-

다음 시간에는 뜨거운 감자였던 조건적 표현식(C에서 보통 삼항 연산자라고 부르는 그것)에 대해서~

"저는 구글에서 일하고 있는 누구입니다. 구글에서 일하는 것이 관심 있으시면 저에게 알려주세요." 작년부터 오픈소스 메일링 리스트 곳곳에서 볼 수 있는 이제는 흔한 구글의 구인 문구. 작년에는 그래도 기존에 오픈소스 커뮤니티에 적극적으로 참여하고 있던 사람들, 특히 영향력이 있는 유명한 사람들이 자발적으로 올려서 친구들에게 좋은 기회를 제공해 주려고 하는 의도가 강했습니다.

그런데, 얼마 전부터 구글이 사람이 많이 모자랐는지, 광고 대상 커뮤니티의 관례에 대해서 잘 알지 못하는 리크루터들이 메일 양식을 만들어서 이름과 사이트 이름만 바꿔가면서 메일을 돌리고 있고, 심지어 메일링 리스트에 올리는 일까지 발생하고 있습니다. 저도 그동안은 말로만 듣고 있다가 오늘 그 메일을 직접 받게 되었는데, 메일링에서 그런 메일 받았다는 사람들이 많은 것 몰랐으면 괜히 좋아할 뻔 했습니다. 흐흐흐..

구글은 오픈소스 개발자들에게 무작정 스팸 뿌리듯이 구인 광고를 뿌리기 보다는, 정말로 각 개인이 어떤 특징이 있는지 뭐에 관심이 있는지, 각 커뮤니티의 특성이 어떤지를 파악한 다음에 좀 더 덜 스팸스럽게 보내는 정도의 성의를 보여야 될 것 같습니다. 이렇게 계속 스팸 돌리듯 돌려서, 길고 따분하기로 유명한 구글 인터뷰 과정을 거친 다음에 탈락했다는 사람들이 대량으로 나오면 안 좋은 인상이 제곱이 되지 않을까 싶군요. 지금 취하는 형식으로는 "대출승인 안 되신 분 다시 신청 받습니다", "한의사의 꿈 당신도 이룰 수 있습니다" 이런 메일들과 얼마나 차이가 있을까요..

PyCon 2006이 끝나면서 스프린트의 결실이 속속 올라오고 있습니다. 귀도보다 더 파이썬을 잘 안다고 말할 수 있는 몇 명 중의 하나인 팀 피터스는 이번 스프린트에서 파이썬 메모리 관리 시스템을 작업해서 드디어 끝을 냈다고 합니다. (팀의 얼굴이 궁금하시면, 위의 pycon 홈페이지에 보면 앞에 나오는 사진에서 왼쪽부터 순서대로, 귀도, 팀, (떼), 배리, 짐 입니다.)

스택에 객체 할당을 하지 않는 언어들의 속도에 가장 치명적인 부위 중의 하나가 바로 객체를 위한 힙 할당 부분인데, 파이썬은 이 문제를 해결하기 위해서 2.3부터 pymalloc이라는 것을 넣어서 비슷한 크기로 할당하는 메모리들을 풀로 관리해서 한꺼번에 크게 할당하고, 해제되더라도 pymalloc 측에서 다시 풀에 넣어서 관리를 하는 방식을 취하고 있습니다. 따라서, 시스템 라이브러리 측의 힙 관리가 단순해 지고, 메모리 단편화(fragmentation)가 줄기 때문에, 대략 20~30% 정도의 속도 향상이 있었습니다.

그런데, 이 문제가 또 다른 문제를 불러 일으키는데, 메모리 해제가 일어나더라도 pymalloc은 메모리를 시스템의 free함수로 해제하지 않고 그냥 스스로 계속 다 가지고 있기 때문에, 메모리를 먹기는 먹지만 절대로 뱉지 않는.. 마치 집을 늘일 수는 있지만 줄여서 살 수는 없다는 것을 몸소 실천하는 태도를 보입니다. 그래서, 임시로 100만개짜리 리스트를 만들었다가 삭제하면 그 리스트에 쓰려고 할당한 메모리가 계속 쫓아다녀서, 오랫동안 파이썬이 돌아가면 메모리가 모자라는 시스템에서는 난감한 상황이 옵니다. 그래서, 결국에는 소형 시스템에 들어가는 경우에는 pymalloc을 빼라는 매뉴얼이 부지기수로 나올 정도가 되었습니다.

여러 사람들이 도대체 왜 메모리가 늘기만 하고 줄지는 않느냐! 파이썬 메모리 새는 것 아냐! 하고 굉장히 주기적으로 따졌는데, 답장은 어쩔 수 없다 우리가 하는게 가장 간단하고 빠른 방법이다, 그것 싫으면 pymalloc 빼고 컴파일해라.. 이런 답장들로 일관 했었습니다. 그러던 중, 2005년 PyCon에서 Evan Jones라는 사람이 "잔다르크처럼 나타나"서는(여자라는 말은 아닙니다;;) 체계적인 설명과, 설명에 따라 구현한 패치의 벤치마크까지 들고 와서 발표하는 사건이 일어났습니다. 그래서, 그동안 몰라요~ 하고 있던 파이썬 개발자들이 번쩍 하면서 이 패치를 긍정적으로 검토하기로 했고, 이번에 이렇게 마무리 되게 된 것입니다.

(큰 리스트 할당하고 나서)
perky 81759 59.8  9.0 102200 93280  p3  S+    4:24PM   0:03.73 ./python testmem.py
(그 리스트를 지우고 나서)
perky 81759 30.2  7.7 87752 79484  p3  S+    4:24PM   0:03.91 ./python testmem.py

결과적으로, 이제 숫자 1000000개가 들어가 있는 리스트를 할당했다가 풀면 메모리가 줄어듭니다. FreeBSD에서는 phkmalloc이 또 내부적으로 하는 짓이 있어서 윈도우에서처럼 극적으로 줄어들지는 않는데.. 그래도 저거라도 줄어드는게.. :)

그 원리는 자료구조를 공부하신 분이면 쉽게 예상할 수 있듯이, 객체 해제가 일어날 때 메모리 풀이 다시 프리 리스트에 추가되면서 아레나가 완전히 비게 되면 메모리를 해제하는 구조로 일어납니다. 역시 C 언어로 되어 있는 터라, 모든 포인터를 모두 따라가서 고칠 수는 없기 때문에, 듬성듬성 차 있는 아레나들을 정리하기 위해서 적극적으로 풀을 모으는 등의 행동은 어렵습니다. 그 문제를 해결하기 위해서 이 패치에서는 그냥 많이 차 있는 아레나들을 풀 프리 리스트의 앞쪽에 가도록해서, 많이 찬 것을 먼저 채우도록 한 것으로 보입니다.

그동안 메모리 안 줄어들어서 고생하신 파이썬 사용자 여러분 힘 내세요 -O-

총 무게 14.5kg..(옆에 있는 토끼군은 빼고~) 가장 많이 든 날은 하루에 5과목;; 아고 학교 어떻게 다니나.. T_T

이제 파이썬에 새로운 것이 계속 들어와도 놀라지 않을 만큼, 파이썬은 끊임없이 새로운 문법이 매 버전마다 들어오고 있습니다. 파이썬 2.3에서 generator/bool, 2.4에서 generator expression이 하이라이트였다면, 2.5에서는 단연 PEP-343 with 절이 가장 주요한 문법의 변화가 되겠습니다.

with 절은 이미 다른 언어에 많이 소개가 되어 있는 개념을 구현하기 위한 것인데, ruby의 block이나 자바의 synchronized 같은 것들과 비슷한 개념을 지원합니다. 그렇지만, 비주얼 베이식의 with같이 네임스페이스를 줄이는 목적으로 쓰는 것은 아니기 때문에 서로 다릅니다.

with 절은 원래 PEP-340 Anonymous Block Statements에서 소개되었던 문맥 처리 기능들을 PEP-340이 몇가지 문제로 인해서 거부되자 대체 문법으로 등장한 것입니다. with 절의 문법은 이렇습니다.

with EXPR as VAR:
    BLOCK

as VAR 부분은 생략이 가능합니다. 이렇게 쓰면 내부적으로 다음과 같이 번역이 되어서 실행이 되게 됩니다. (소문자로 된 변수들은 VM 내부적인 변수이므로 소스코드에서는 접근 가능하지 않습니다.)

ctx = (EXPR).__context__()
exit = ctx.__exit__  # 아직 호출하지는 않음
value = ctx.__enter__()
exc = True
try:
    try:
        VAR = value  # "as VAR"이 있을 경우에만
        BLOCK
    except:
        # 여기서 예외 처리를 함
        exc = False
        exit(*sys.exc_info())
finally:
    # 지역적이지 않은 분기는 여기서 처리함
    if exc:
        exit(None, None, None)

번역 부분을 약간 살펴보면 새로운 메쏘드 이름인 __context__, __exit__, __enter__를 쓰고 있습니다. with x as y: 라고 쓰면 x.__context__()를 호출한 다음, 그 녀석이 리턴한 객체의 __enter__()를 호출해서 리턴된 것을 y에 넣어줍니다. 단, with절은 블럭 안에서 프레임이 생성되지 않기 때문에 y의 유효영역은 with절 안이 아니라, 외부의 지역 네임스페이스입니다. (밑줄 쫙~)

자.. 과연 이런게 어디에 쓸모가 있을까! 생각해 보면, 당장 생각 나는 것은 임시 파일을 생성했을 때 귀찮게 finally로 감싸서 파일 지워주는 경우가 생각납니다. 그런데, 이런 사용 사례들을 일일이 위와 같이 __context__, __enter__같은 것을 다 구현해 주기는 굉장히 귀찮기 때문에, 실제로는 제너레이터로 간단하게 구현할 수 있도록 contextlib이라는 모듈이 신설되었습니다. contextlib에는 contextmanager라는 데코레이터가 있어서, 제너레이터를 구현할 때 @contextmanager를 통과시켜 주면 쉽게 with용 컨텍스트매니저로 변신을 시켜 줍니다. closing이라는 것도 있어서 with를 벗어나면 자동으로 파일 닫게도 할 수도 있고요~

한 번 시험해 보기 위해서, 대표적인 with절 예상 사용 사례인 SQL 데이터베이스의 트랜잭션 처리 부분을 한번 해 봤습니다. :)

from __future__ import with_statement
from contextlib import contextmanager
import MySQLdb

@contextmanager
def mysqlconn(hostname, username, password, database):
    conn = MySQLdb.connect(hostname, username, password, database)
    curs = conn.cursor()
    try:
        curs.execute('BEGIN')
        yield curs
    except:
        curs.execute('ROLLBACK')
        raise
    else:
        curs.execute('COMMIT')
    finally:
        conn.close()

with mysqlconn('localhost', 'user', 'passwd', 'db') as curs:
    curs.execute('select count(*) from schedule')
    print curs.fetchone()

with절에 진입하면서 자동으로 데이터베이스 접속을 맺어주며, 안에서 예외가 발생하면 롤백하고, 예외가 발생하지 않고 빠져나오면 자동으로 커밋하게 해 줍니다. 이와 비슷하게 threading.Queue같이 쓰레드 간 동기화나 임시 객체가 생성되는 온갖 사용처에 아주 유용하게 쓰일 수 있을 듯 합니다~ (위 예제를 유심히 보시면 with절 외에도 2.4에서는 안 되던 문법이 2가지 숨겨져 있습니다. 이히히히~)

그런데, with는 새로운 키워드이기 때문에, 2.5에서는 from __future__ import with_statement를 해야지만 사용할 수 있고, 2.6부터는 정규 키워드로 지정될 예정입니다.

자, 이제 파이썬이 프로그래밍을 안 해본 사람도 하루만에 배울 수 있는 언어라는 굴레에서 해방되었습니다. -O-;;;;;

제럴드 와인버그의 또 다른 유명한 책 《대체 뭐가 문제야? Are Your Lights on?》가 번역되어 나왔습니다. 먼저 번역서가 나온 《컨설팅의 비밀》도 무척 재미있게 읽었기에, 이 책도 다른 책 읽던 도중에 참지 못하고 덥썩 읽어버렸습니다. (지금 사 놓고 안 읽고 쌓아둔 책이 5권 =.=;)

이번 책은 문제를 해결하는 전문 컨설턴트가 아니더라도, 인생에서 문제가 한 번이라도 있었던 사람들이라면 언제나 그 문제를 해결할 때 도움이 될 만한 내용을 다루고 있습니다. 아침 먹다가 밥풀 흘리는 사소한 문제부터 시작해서, 버스에서 출근할 때 자리에 못 앉아서 피곤하게 서있다가 낮에 존다던지, 한 번 죽을 때 마다 수천만원의 손실이 발생하는 프로그램이 왜 죽는지 모를 때 문제를 "다루는" 방법에 대해서 시야를 넓혀줍니다.

SI 프로젝트를 하다가 꼬일 때, 대체로 보면 문제가 뭔지 제대로 파악을 못한 경우가 많습니다. 저도 2004년에 했던 K모사 프로젝트를 되돌이켜 보면, 처음 1달간, 발주사의 구체적인 문제가 무엇인지, 무엇이 필요한지, 해결 방법이 어떤 영향을 주는지를 파악하지 않고, 나름대로의 상상을 곁들여서 마구 커다란 스펙을 잡아놓고 진행하다보니 결국에는 기능은 엄청나게 많고 발주사는 그래도 기능이 모자란다고 화를 내는 지경에 이르렀던 적이 있습니다. 프로젝트를 다 끝내고 나서 되돌이켜 보면 그 사람들이 필요했던 것은 우리가 만든 기능의 극히 일부분에 지나지 않는데, 문제가 뭔지도 모르고 나름대로의 가정을 덧붙인데다가, 문제를 제시한 사람들이 말하는 해결방법을 곧이 곧대로 다 듣다보니 일이 커질 뿐만 아니라 문제 해결도 어려워지게 되었던 정말 살아가는데 이렇게 하면 안 되는구나 하는 온갖 교훈을 다 얻은 프로젝트였지요. -.-;;

이 책에서는 문제 해결의 가능성을 넓히기 위해서, 누구의 문제인가?, 무엇이 문제인가?, 문제의 핵심은 무엇인가? 같은 기초적인 것을 찾는 방법을 왕공룡씨 엘리베이터을 사례로 들고 있습니다. 한 건물의 엘리베이터 트래픽 문제가 주지사나 법의 문제까지도 생각해 볼만한 가치가 있다는 점이나 엘리베이터 주위에 낙서할 수 있는 크레용을 놓는 것으로도 해결이 가능하다는 것 같이 문제 자체에 더 집중하면 얻을 수 있는 손 쉬운 해결 방법을 찾는 것을 보여주고 있습니다.

책이 굉장히 짧기 때문에, 내용을 더 소개하다보면 스포일러가 돼 버릴 것 같아서, 내용 소개는 여기서 줄이고, 인상적이었던 부분 몇 개 인용해 봅니다. :)

유머 감각이 없는 사람의 문제를 해결하려고 노력하지 마라.
- 책 44페이지

(13명의 학생 중 1명이 교실에서 자꾸 담배를 피울 때 학생들이 토론해서 해결하려고 하는 이야기 중에서)
만약 앞서의 답이 3이었다면, 즉 '교수'의 문제였다면 그 결과가 어떠했을까 생각해 보자. 아마 다음과 같이 하지 않았을까?

• '담배를 피울 수 없도록' 규정을 만들고 흡연 학생이 수업을 그만 두도록 해서 그가 분개하도록 만든다.
• 담배를 피우도록 규정을 만들어서 담배를 못 피우는 일부 학생들이 수업을 그만두도록 하거나 혹은 담배 연기의 영향으로 점심조차 못 먹게 만든다.
• 흡연 강의와 금연 강의로 나누어서 날짜나 시간을 분리하여 모든 사람을 불만족스럽게 만든다.

그러나 이처럼 무언가를 규정으로 만드는 대신 교수는 그 자신만의 문제해결 교훈을 따랐다.

그들 스스로 문제를 완벽하게 풀 수 있을 때에는 그들의 문제 해결에 끼어들지 않는다.
- 책 111페이지

학교에서 제대로 된 문제 해결사들을 배출하지 못하는 이유는 아마도 학생들에게 무엇이 문제인지 찾을 수 있는 기회를 주지 않았기 때문알 것이다. 학교에서는 선생님들이 문제라고 '말하는' 것이 그냥 문제인 것이다.
- 책 164페이지

개강을 기념해서 그동안의 단아한 디자인에서 좀 변화를 줘서 어둠컴컴하고 습한 디자인으로 바꿔 봤습니다. -ㅇ- 제목을 붙이자면.... "해그리드의 주방" 쯤..? (별 생각 없이 -ㅇ-)

요새 유행하는 스타일로 본문만 흰 바탕에 나오게 했구요~ 전반적인 글꼴 크기를 약간씩 키웠습니다. 그래서 스크롤을 안 하고서는 한 화면에서 볼 수 있는 것이 별로 없군요! 하하하.. 제가 요새 눈이 침침해서 큰 글씨가 좋아져서 --;;;;;

작업 도중에 css 문제 해결에 도움을 주신 소타님과 klutzy님 감사합니다~

쓰시는 브라우저에서 이상하게 보이는 부분이 있으면 알려주세요~