python

방금 파이썬에 FreeBSD 6 지원을 추가 했습니다. 주로 테스트 코드들과 plat-freebsd6/IN.py, 그리고 setup.py에서 플랫폼에 따라서 모듈을 선택하는 부분이 변경되었습니다. 흐흐;

짠~

이히히;

요즘 회사 일이 너무 바빠서 퇴근도 눈치보고 하는 중이라.. 뭐 재미있는 일을 할 시간이 없네요.. 아흑흑 iso-2022 코덱 컴파일 제대로 안 되는 문제도 벌써 PR이 5개나 올라오고 이거 뭔가 조치를 취해야..

최대용량 파이썬 배포본으로 유명한 Fourthought의 CEO인 Uche씨가 블로그에 Python 2.4 is coming이라는 글을 썼는데 CJKCodecs에 대해서 좋게 썼네요 ;;

그리고 두번째 문단에서 지원님이 구현하신 제너레이터 익스프레션에 대해서도 굉장히 우호적으로~ 으히히. 과연 데코레이터와 스트링 인터폴레이션에 대해서도 이렇게 말할 수 있을지는… (흐읍~ 흐읍~)

(뭔가 자랑하고 나니 뻘쭘하다.. -o-)

평소에 하루에 5통 내외의 낮은 소통을 갖고 있는 파이썬 개발자 메일링 리스트에 요즘 하루에 100통 정도의 엄청난 난리가 나고 있습니다. 바로, PEP318 펑션/메쏘드 데코레이터 때문인데요. 작년부터 엄청난 토론이 있었지만 별로 예쁜 문법이 안 나왔다가, 이번엔 결국 귀도와 앤써니의 합작으로 2.4a2 릴리스 이틀 전에 기습적으로 CVS에 커밋되었습니다. 보통은 커밋 되기 전에 소스포지나 개발자 메일링 리스트에서 여러 주를 토론을 하고 리뷰를 하다가 넣는데 이번엔 거의 우리나라 국회 날치기 처리하듯이.. ;;

이번에 들어간 문법은 @method 이렇게 펑션 윗줄에 연달아 쓰는 것인데, 이 외에는 리스트를 앞이나 뒤에 달아쓰는 것, | 연산자 활용하기, ^연산자 활용하기, AS 활용하기 등등 별의 별 나올 수 있는 문법은 다 나왔지만 결국은 몇명은 좋아하고 몇명은 다 싫어하는 문법들이란 것이 나오고 말았습니다. 메일이 수백개가 오간 뒤 어느정도 @method 데코레이터 문법이 어느정도 지지자들을 모으고 있는데, 이 문법은 새로운 기호를 사용해서 기존 파이썬 기반 확장 문법을 사용하던 ipython이나 Leo 등등에서 심각한 문제를 만들고 하위호환성 보장이 전혀 안 된다는 문제가 있지만 생각보다 쓰다보면 그다지 안 예쁘지는 않다는 장점이 있군요; 저도 처음엔 펄 같아보여서 아주 싫었는데 그런대로 쓰다보니 괜찮네요 흐흐; -ㅇ-;

이번 데코레이터 날치기 통과를 계기로 파이썬이 싫어졌다고 공공연히 밝히는 유명한 개발자들이 굉장히 많기는 하지만.. 아무래도 print >> fp 문법처럼 결국은 모두 다 싫어하면서도 쓰는 문법이 되지 않을까 생각해 봅니다 –;

파이썬은 소스가 수도 코드라서 아무래도 버그 추적할 때 문서보다는 소스를 찾아댕기는 일이 많습니다. 그런데, /usr/local/lib/python2.3/site-packages/twisted .. 뭐이렇게 길다랗게 나가는 디렉토리를 매번 일일이 치고 들어가는 건 참 고통스러운 일인데.. 그래서, pydoc처럼 간단히 vi를 열 수 있는 녀석을 만들어 봤습니다.

vipy {모듈이름} 하면 바로 해당 소스를 vi로 띄워줍니다.

파이썬 릴리스 엔지니어인 앤써니 백스터씨에 따르면 이번 주 목요일에 파이썬 2.4a2를 릴리스할 예정이라고 합니다. 2.4 브랜치의 첫 릴리스이자 MSI 인스톨러가 실제 사용이 가능할 지 알아보는 첫 알파 릴리스였던 2.4a1에 이어 이번 2.4a2에서는 2.4의 가장 큰 싸움터였던 318 메쏘드 데코레이터의 시험 무대가 됩니다.

메쏘드 데코레이터는 필요성에 대해서는 대체로 최소한 +0 정도는 주고 있었지만, 공감을 얻어내는 깔끔한 문법이 하나도 나오지 않은 상태에서 반발을 사는 안만 수십개가 난립하고 있었는데, 우선 2.4a2에서 귀도의 결정으로 앤써니가 자바 스타일 문법을 그대로 사용한 것을 우선 트렁크에 넣었습니다. 이렇게 됩니다.

지금까지 함수 끝에다가 test = staticmethod(test)했던 다른 언어에서 건너온 사람들이 거부감을 느낄 듯 한 문법상의 문제점을 해결을 해서 뭐 그럭저럭 괜찮은 것 같기는 하지만서도.. @라는 여태까지 파이썬에서 사용되지 않았던 기호를 하나 더 사용하게 된 것은 조금 거부감이 듭니다. 뒤에 as붙이는 거나 []안에다 마구 써대는 것 보다는 그래도 훨씬 나은 것 같네요;;

그리고, 2.4a2에서는 CJKCodecs 1.1이 머지돼서 HKSCS와 JIS X 0213:2004지원이 원활해졌습니다. 또한, 인터랙티브 셸에서 sys.stdin.encoding을 존중하지 않던 문제가 해결되어, 이제 u”한글” 이런 식으로 인터랙티브 셸에서도 쓸 수 있게 되었고, 일본 사람들이 shift-jis 로캘에서 몇몇 글자를 입력하면 이스케이프때문에 에러가 나는 문제가 해결됩니다.

그 외에 국제화와 관련이 없는 주요 문제들로는

• 그동안 임포트 중에 실패한 모듈들이 모듈 캐시에 남아서, 그 다음에 또 임포트하면 마치 에러가 안 난 것처럼 배시시 거리고 있는 현상이 이제 고쳐졌습니다.

• None이 컴파일러에서 상수형으로 처리되어 더이상 None = 1 같은 처리가 불가능해졌습니다. (..)

• SSL 소켓을 넌블러킹 소켓으로 사용할 수 있게 되었습니다.

• threading 모듈의 쓰레드 오브젝트에 local이라는 속성이 추가돼서 TLS(Thread-Local Storage) 사용이 가능해 졌습니다.

• Optik이 1.5로 업그레이드 되었습니다.

드디어 어제 있었던 OSCON 2004의 마지막 키노트를 앞두고 2000명의 관중 앞에서 약속대로 Parrot팀의 대표인 Dan Sugalski가 Guido에게 크림 파이를 맞았습니다. 그리고 10달러와 맥주 12팩을 받았다고 합니다. 받은 맥주들은 밴쿠버 파이썬 워크샵에서 나눠먹는다는군요. ^^^;

이번에 패럿팀에서는 Leopold Toetsch가 좀 늦게 작업을 시작해서 혼자서 열심히 단기간에 많은 걸 이뤄내기는 했지만, Guido가 패럿을 X먹이기 위해 만들었다고 알려진 패럿 벤치의 b0.py를 구현하는데 결국은 시간 부족으로 실패해서, 다른 벤치마크 부분은 그런대로 속도가 나왔음에도 불구하고 진 것으로 처리가 됐습니다.

Leo의 예상으로는 구현을 다 끝내면 CPython보다 Parrot위의 파이썬이 3배는 더 빠르지 않겠느냐고 밝혔는데 글쎄요 흐흐 두고 볼 일이겠죠;; -O-; 하여간 그래도 패럿의 참패로 끝나지는 않아서 다행스럽습니다.

반면, Iron Python은 현재 b0.py도 완벽하게 통과하고 있는데, 이제 Jim Hugunin이 MS CLR 팀에 합류했다는 점에서 더욱 기대가 됩니다. (역시 편파적인 멘트를 해 본다;; )

아아 한동안은 Iron Python 릴리스 특집을 계속 쓸 것 같은.. 흐흐

Iron Python을 이제 받아서 대충 한번 둘러 봤습니다. 프로젝트 자체는 Visual Studio .NET 기반의 프로젝트 파일로 되어있고, mono에서 컴파일이 가능한 프로젝트 파일은 따로 없는 듯 합니다. 그렇지만 다행히도 컴파일된 바이너리가 들어있어서 빌드 걱정 없이 그냥 실행해 볼 수 있었습니다.

트레이스 백 모양이 파이썬 트레이스백이 아니라 자바 형식이라 좀 어색하군요 흐흐; 그리고 sys.platform이 웬 ‘java-clr’ –;; 아직 os모듈은 없고, 현재 Iron Python에 들어있는 모듈은 __builtins__, imp, math, nt, re, struct, sys, time이 있습니다. 뭔가 벤치마크를 위해 time을 빼놓지는 않았다는 느낌이.. :

CPython보다 빠르다는 속도를 한번 시험해 봤습니다. 테스트 코드는 뭐 아주 간단한 파이썬 취약성 루틴의 대표적인.. while안에서 덧셈하기.. 흐흐;;

결과는

Iron Python 0.6

CPython 2.3

CPython 2.4

0.972

0.625

0.595

아아. 아쉽게도(?) CPython이 간단한 루틴에서는 더 빠르군요. ;; (기분이 묘하다..)

그리고, .NET 클래스 라이브러리 쓰는 것도 어느정도 잘 되는 듯 합니다.

괜히 제가 만든 mono cp949 코덱 시험도 한번 –;

System.Text.Decoder.GetChars의 마지막 2 인자를 어레이랑 어레이 인덱스로 줘야하는데, 어레이를 파이썬에서 어떻게 주는지 알 수가 없어서 일단은 –;;;;;

지난 PyCon에서 약속했던 대로 Jim Hugunin이 드디어 Iron Python을 일반 공개 했습니다. 버전이 0.6이군요. 아아 가슴이 쿵쾅쿵쾅.

시험해보고 더 많은 소식 올리겠습니다. Iron Python 만세!!

그런데 홈페이지를 보니 Jim이 8월부터 Microsoft의 CLR 팀에서 일하게 됐다는군요.. -O-;; 앞으로도 계속 공개 됐으면 좋겠는데.. 어떻게 될지..

드디어 한국어 코덱이 들어간 최초의 파이썬 릴리스인 2.4a1이 나왔습니다. 으흐흐~ 마비노기때매 CJKCodecs 1.1을 못 넣은 것이 정말 한스럽지만.. 마비노기 나빠요~

프비 포트도 앤쏘니가 파일 올리자 마자 바로 업데이트 했습니다~ 흐흐; 프비 사용자는 바로 cd /usr/ports/lang/python-devel && make install clean 하세용~

그리고, 이번 주 토요일에는 freenode에서 Python Bugday 2차가 열릴 예정입니다. 벌써부터 2.4a1 받은 사람들이 버그를 와장창 올리고 있는데, 이번에는 회사에 토요일, 일요일도 나오라고 하는 바람에 버그데이 참가를 못 할 것같아서 무척 아쉽습니다. 으흐흐. 지원님이 참가하실 것 같으니 관심 있는 분들은 같이 참여를~~

“파이썬은 C로 되어있어서 뭐든 만들 수 있어~”

“그럼 운영체제도 만들 수 있어?”

“응 그럼, 가능 할꺼야. (…. 속으로는 의심을 한다..)

“설마.. (역시나 의심 한다..)

파이썬을 광고하는 장면에서 자주 있는 장면이었습니다. 아 이제 이런 말이 그다지 비현실적인 말이 아니라는 것을 증명해 줄 만한 프로젝트가 등장했군요. 바로 Unununium 입니다.

굉장히 이상한 스펠의 이 단어는 대충 “운운우니움”정도로 읽으면 될 듯 합니다. 여기서 “ㅜ”들은 모두 moon에서의 “우~”같은 장음이기 때문에 읽는데 시간이 좀 걸립니다. 다 같이 따라해 보세요~ “운운우니움” ..;;;

이 운영체제는 기존의 운영체제들이 구현의 간편성, 엔지니어링 측면에서의 디자인을 기반으로 했기에, 사용자 측면에서의 여러 직관적이고 우아한 기능들을 제공해 주지 못하고 있는 것에 불만족을 느낀 저자가 뭐 이걸 좀 바꿔보겠다고 한 것인데, 파일시스템이 portalfs나 LUFS처럼 여러 프로토콜을 밑에 끼고 들어갈 수 있도록, 일반적인 통합을 이루고, 애플리케이션 프로세스들이 서로 완연한 상호작용으로 DCOM이나 bonobo같은 컴포넌트 이상의 상호 통합을 이룰 수 있도록 한다는군요. 그리고, OS 자체 Persistence를 지원해서 그냥 껐다 켜도 원래 OS 상태로 돌아가게 한다는데.. 뭐 대충 구현한다는 것은 어쨌거나 대체로 기존에 있는 기술이랑 비슷하긴 하네요 흐흐;;

그런데, 실제로 파이썬으로 다 하는 것은 아니고, 지금은 상당수가 어셈블리로 구현이 되어 있긴 한데, 그 위에 많은 부분을 파이썬으로 구현할 예정이라고 합니다. 그런데, 파이썬으로 구현하면 느리지 않겠느냐 하는 것에 대한 해결책은 파이썬이 느린 것은 언어 자체가 느린 것이 아니라, 구현이 느릴 뿐이니 자기가 파이썬을 빨리 해 보겠다는데.. 과연 그 네임 스페이스를 그대로 살린 채로 파이썬을 빠르게 할 수 있을 지는 의문입니다. ㅎㅎ;;;

빠른 시간 안에 큰 실적을 낼 것 같아 보이지는 않지만, 이런 ㅂㅌ 프로젝트가 하나 진행 되면 아무래도 부산물이 제법 나올 테니 그게 기대가 되는군요. ^^;;