python – Page 8

파이썬 커버리지 분석 도구 & 에디터

March 16, 2006 by hyeshik

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

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

파이썬 최근 소식 몇가지~

March 15, 2006 by hyeshik

요새 파이썬 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개 정도가 새로 들어와서 좀 늘었습니다;;)

자바스크립트와 파이썬

March 11, 2006 by hyeshik

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

파이썬 2.5 미리보기 4편: ctypes

March 9, 2006 by hyeshik

>>> 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'

>>> 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 모듈에서도 쓸 수 있을 것 같고요~

일본 Python Workshop the Edge 2006

March 6, 2006 by hyeshik

일본 파이썬 유저그룹에서 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 미리보기 3편: incremental codec

March 6, 2006 by hyeshik

파이썬 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을 쓰는 세션을 하나 보겠습니다. 🙂

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

>>> 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로 한 번 해 보면..

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

>>> 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에서 보통 삼항 연산자라고 부르는 그것)에 대해서~

파이썬 2.5 미리보기 2편: Arena-freeing obmalloc

March 3, 2006 by hyeshik

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

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

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

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

<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

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-

파이썬 2.5 미리보기 1편: with 절

March 2, 2006 by hyeshik

이제 파이썬에 새로운 것이 계속 들어와도 놀라지 않을 만큼, 파이썬은 끊임없이 새로운 문법이 매 버전마다 들어오고 있습니다. 파이썬 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

1 2	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)

ctx = (EXPR).__context__()

exit = ctx.__exit__ # 아직 호출하지는 않음

value = ctx.__enter__()

exc = True

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()

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-;;;;;

남성을 위한 유닛테스트 UI – 테스토스테론

February 26, 2006 by hyeshik

남성스러운 파이썬 유닛테스트 인터페이스, 테스토스테론이 나왔군요. 헐헐.. 이름도 참.. -O-

스크린캐스트를 보면 curses UI로 상당히 깔끔하게 유닛테스트를 할 수 있도록 해 놨습니다. 이클립스 부럽지 않네요~ 🙂 그럼 이제 에스트로젠이 예쁜 GUI로 나올 차례일까요.. (기대!)

파이썬 IDE가 쓸만한 것이 없는 이유?

February 20, 2006 by hyeshik

파이썬 IDE로는 BoA 건설역군^^이나 상용인 WingIDE 같은 것들이 대표적입니다. 파이썬에 포함된 IDLE도 있지만, 다른 IDE 들에 비하면 IDE라기 보다는 그냥 에디터와 커맨드라인을 합쳐놓은 것 정도라고 할 수 있겠지요.

그동안 파이썬 IDE가 좋은 것이 잘 안 나오는 이유는 무엇인가! 에 대해 돈이 안 돼서 안 나온다, 사용자가 별로 없어서 안 나온다 등등 여러가지 분분했는데, Thinking in Java/C++/Python 씨리즈로 유명한 브루스 엑켈씨가 새로운 의견을 내놓았는데, 제법 설득력이 있군요.

파이썬은 이미 입력할 것들이 충분히 짧기 때문에, 자바같이 1000타 코더가 배출될 정도로 입력할 필요가 없어서, IDE가 생산성 향상에 별 필요가 없다는 주장입니다. dir()만 해 보면 뭐가 있는지 대충 보이고, 인터랙티브 모드에서 시험해 보면 오토 컴플리션 없이도 나름대로 편하게 개발할 수 있다는 것입니다.

물론, 뭐 있어서 나쁠 것은 없겠지만, 저도 아직까지 eclipse PyDev가 좋다는 말만 듣고, 아직까지도 별로 쓸 생각은 안 드는게.. 뭐시기가 거시기 한 것 같네요~ 므흐흐…

그렇지만… wxPython의 노가다 앞에서는 무력해지는 파이썬의 생산성.. -.- wxPython을 위한 완벽한 IDE에 목이 말라요!

꼬릿말: 그나저나, 그럭저럭 괜찮은 명령행 히스토리 자동완성 모듈이 나왔군요~