혜식이의 열고 보는 세상
선 코딩 후 테스트식 개발을 할 때에는 커버리지 분석 도구가 꼭
필요합니다. 상용 커버리지 분석 도구 중에서는 파이썬 코드도 예쁘게
분석 결과를 보여주는 것이 있었는데, 아직 오픈소스 도구 중에서는 딱히 마땅한 게 없었는데요, 드디어 하나 제대로 예쁜게 나왔군요.
trace2html! 출력 예시를 보면 trac과 함께 파이썬기반 프로젝트들이 꼭 설치해야 할 프로그램이 하나 늘었네요~ 🙂 (trac 플러그인으로 들어가길!)
비주얼 스튜디오나 델파이/C++빌더 같은 윈도우 기반 IDE들에 익숙한 개발자들이 쓸만한 IDE도 하나 발견했는데, PyScripter 상당히 예쁘군요. 아무래도 델파이 개발자들 눈에 맞춰서 만든 컴포넌트들을 그냥 그대로 갖고 와서 쓰다보니 그렇게 된듯~ 단, 델파이로 되어 있기 때문에 IDE를 고친다거나 포팅한다거나 하는 것은 굉장히 어렵겠습니다. 스크린샷
요새 파이썬 2.5 릴리스 엔지니어링 시작이 임박하면서 여러가지 새로운 소식이 나오고 있어서 몇가지 전해 드립니다. 🙂
오랜만에 한글 PuTTY 새버전을 릴리스 했습니다. 원래는 커서 패치를 업스트림하고서는 더 이상 안 건드리려고 했는데… 정치력 부족으로 아직 패치를 밀어넣지 못해서 -.-;; ㅠ.ㅠ
이번 릴리스의 변동점은.. 아무래도 새 버전이니까 기분이 좋은데.. 뭐가 바뀌었는지는 잘 모르겠네요 하하하.. -ㅇ- 궁금하신 분은 릴리스 노트를 보세요. +_+
그나저나 버전 올라갈 때마다 코드가 엄청 많이 바뀌어서, 매 버전마다 매번 새로운 방식을 연구해서 패치하는 게 무척 귀찮아서.. 얼른 정치력 연마를 좀 더 해야겠네요..
알림: 이 글은 이전 스크립트 자체에 대한 글이며,
이글루스나 다음 등 사이트 자체에 대한 어떠한 선호도
의도된 것이 아닙니다. 저는 둘 다 안 쓰기 때문에 별로
신경쓰지 않습니다. ^^
어느 분의 부탁으로 이글루스에서 다른 사이트로 블로그
이사를 하는 스크립트를 만들었습니다. ==>
Blogyltransferase 1.0 다운로드 (win32용), 소스 코드 및 타 플랫폼 (svn)
두 번째로 만들어 본 wxPython 프로그램인데, 이제 그런대로
익숙해 져서 크게 불편하지 않네요. 하하하.. (그새 배신을;;)
이글루스의 기본 스킨이 워낙 잘 되어 있어서 스크린 스크래핑
하기에 굉장히 좋았습니다. BeautifulSoup의 특성을 만끽할 수 있는 최고의 실험 재료가 아닐까 하네요. +_+
앞으로 다른 API도 적당한 것이 있다면 다음 블로그 API외에 다른 것도 지원할 수도 있겠습니다. (MetaWeblogAPI같은 것은 코멘트나 트랙백을 옮길 방법이 마땅찮더군요.)
사용 방법은 http://xxxx.egloos.com/ 의 xxxx를 블로그 이름에 넣고, 다음 블로그로 옮기는 경우에는 다음 블로그를 먼저 개설하고, 다음넷 사용자 이름과 비밀번호를 입력하고 “전송 시작!”을 누르면 됩니다.
이사가 잘 되었으면 이 글에 트랙백을 보내주세요. 🙂
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
>>> 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을 쓰는 세션을 하나 보겠습니다. 🙂
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
>>> 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로 한 번 해 보면..
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
>>> 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라는 사람이 “잔다르크처럼 나타나”서는(여자라는 말은 아닙니다;;) 체계적인 설명과, 설명에 따라 구현한 패치의 벤치마크까지 들고 와서 발표하는 사건이 일어났습니다. 그래서, 그동안 몰라요~ 하고 있던 파이썬 개발자들이 번쩍 하면서 이 패치를 긍정적으로 검토하기로 했고, 이번에 이렇게 마무리 되게 된 것입니다.
|
1 2 3 4 |
<b>(큰 리스트 할당하고 나서)</b> perky 81759 59.8 9.0 102200 93280 p3 S+ 4:24PM 0:03.73 ./python testmem.py <b>(그 리스트를 지우고 나서)</b> perky 81759 30.2 7.7 87752 79484 p3 S+ 4:24PM 0:03.91 ./python testmem.py |
결과적으로, 이제 숫자 1000000개가 들어가 있는 리스트를 할당했다가 풀면 메모리가 줄어듭니다. FreeBSD에서는 phkmalloc이 또 내부적으로 하는 짓이 있어서 윈도우에서처럼 극적으로 줄어들지는 않는데.. 그래도 저거라도 줄어드는게.. 🙂
그 원리는 자료구조를 공부하신 분이면 쉽게 예상할 수 있듯이, 객체 해제가 일어날 때 메모리 풀이 다시 프리 리스트에 추가되면서 아레나가 완전히 비게 되면 메모리를 해제하는 구조로 일어납니다. 역시 C 언어로 되어 있는 터라, 모든 포인터를 모두 따라가서 고칠 수는 없기 때문에, 듬성듬성 차 있는 아레나들을 정리하기 위해서 적극적으로 풀을 모으는 등의 행동은 어렵습니다. 그 문제를 해결하기 위해서 이 패치에서는 그냥 많이 차 있는 아레나들을 풀 프리 리스트의 앞쪽에 가도록해서, 많이 찬 것을 먼저 채우도록 한 것으로 보입니다.
그동안 메모리 안 줄어들어서 고생하신 파이썬 사용자 여러분 힘 내세요 -O-
