python

최고의 오픈소스 GUI IDE라고 누구나 인정할 수 있는 Eclipse를 처음 보고서는 파이썬에서도 swt를 쓰면 참 좋겠다는 생각을 했었는데, 생각지도 않은 것이 이뤄져버렸군요.

GCJ를 파이썬 확장에 도입한 거의 최초의 실용 바인딩인 PyLucene이 나온 뒤에, 사실 많은 사람들이 이런 저런 유명 자바 라이브러리에 대한 바인딩을 만들어보고자 했지만, swig도 지원되지 않고 그렇다고 온통 인터페이스와 클래스가 넘쳐나는 자바 라이브러리를 일일이 클래스 하나하나 다 바인딩 만들기도 엄청난 삽질이고 해서 실제로 많은 바인딩이 나오지는 못했습니다. 그래서, PySWT에서는 저자가 여러 시행착오끝에 PyQT에서 사용하는 C++용 파이썬 확장 모듈 제너레이터인 SIP를 고쳐서 자바 클래스로 파이썬 바인딩을 만드는 것을 만들어버렸다고 합니다. 으흐흐 -ㅇ-

일단은 swt 자체가 워낙 방대한 라이브러리이니 과연 이걸 이런 식으로 해도 별 무리가 없을지는 몇가지 시도가 더 있어봐야겠지만, 큰 자바 라이브러리들도 이제 쉽게 파이썬 모듈이 나올 수 있게 됐다는 점에서 큰 의미가 있을 듯합니다. 그리고, PyQt, PyGTK, wxPython등 크로스 플랫폼을 지원하는 파이썬 툴킷들이 모두 PSF 라이선스와 호환되지 않는다는 점에서 딱히 쓸 만한 것이 없었는데, 용량은 엄청 크지만서도 라이선스면에서나 완성도 면에서나 쓸만한 툴킷이 나왔다는 점에서는 반갑네요. 🙂

이제 distutils에 GCJ지원이 들어가는 것과, pyrex와 swig에 자바소스 긁기 지원이 들어갈 차례인건가요? 🙂

지난 목요일인 5월 19일 거의 1년간 하지 못했던 파이썬 마을 작은 세미나를 했습니다. 이번에는 세번째인만큼 지난 번 같은 대동 화합적인 1개 트랙로 수십명 같이 듣기 모드보다는, 오래 지속될 수 있도록 관심사와 숙련 정도에 따라 필요하신 곳에 참여하실 수 있도록 2개의 트랙을 준비해서 동시에 옆 방에서 진행하는 방식으로 바꿨습니다. 사실 100명 넘게 참여하는 세미나 같으면야 당연히 이렇게 하지만.. 겨우 10명 하면 많이 하는 곳에서 이렇게 2개로 나눈다는 것이 좀 부담스럽기는 했습니다. 쿠쿠 그런데 뭐 대충 성공! (각 트랙별로 10분 정도씩 참가해 주셨습니다.)

이번에 진행한 트랙은 2개로 1번 트랙에서는 넓고 시원하고 탁 트인 방에서 이만용이사님이 “파이썬 신식 클래스 (new-style class)”를 진행하셨고, 2번 트랙은 좁고 통풍 안 되고 더운 방에서 제가 파이썬 흑마법이라는 주제로 진행을 했습니다. 각각 1시간 30분씩 진행을 했는데, 제가 진행한 2번 트랙은 더워서 다들 파이썬에 대한 열기가 후끈후끈!! (;;;) 지난 번까지는 계속 회비를 1만원으로 했는데 매번 뒷풀이를 하고 나면 돈이 모자라서 세미나 후유증으로 재정을 고려하고 그래야했습니다. 그래서 이번에는 과감히 1만 5천원으로 회비를 올렸더니만! 뒷풀이 테이블 하나에 안주를 3개씩 시키는 호화스러운 뒷풀이를 할 수 있었습니다. 하하 다들 만족하시는 분위기라.. (비싸서 안 오신다는 분도 있었지만 ㅠ.ㅠ.)

이번 세미나에서 발표한 프리젠테이션과 소스를 올려 두었습니다. 이번에 아쉽게도 못 오신 서지원님꼐서 vnc2swf로 녹화를 하면 어떻겠냐 하셨는데, 제가 아직 사용법을 숙지를 못 해서 못했네요 –; 다음엔 꼭! 🙂

요새 파이썬 개발팀의 주요 이슈는 PEP-340 Anonymous Block 입니다. 거의 다른 이슈들을 완전히 누르고 하루에도 수십통씩 관련 메일이 올라올 정도로 다들 열에 올라 있는데, 이 논의와 비슷한 얘기는 이전에도 몇번 있긴 했지만 딱히 어디로 결론이 나지는 않았었습니다. (PEP-310, PEP-325) 그러나 4월 중순에 C++ 프로그래머였던 사람이 조심스럽게 질문을 한 것에 대한 답글들에서 개발자들이 열을 내기 시작해서, 귀도가 4월 27일에 직접 PEP를 쓰기에 이릅니다.

이번 PEP-340은 현재 드래프트 상태이고, 확실히 의견이 모아진 것도 아니며, 그냥 실험적으로 논의되는 상태를 정리하는 것을 위한 안이지만, 이전의 유사 주제의 PEP들에 비해 상당히 여러 분야를 한꺼번에 통합하고 있고, 신선한 개념을 많이 제공하고 있다는 점에서 뭔가 유사한 것이 약간의 부분이라도 파이썬 2.5에 들어갈 것 같은 감이 듭니다. 으흐흐~ 파이썬 2.5에는 특히 AST가 거의 들어갈 것이 확실시되고 있으니까.. 그 김에 문법도 확 -.-,;;

PEP-340에서 소개하는 Anonymous Block은 파이썬 1.5 이후의 문법 상의 가장 획기적인 변화라고 부를 수도 있겠는데, 사실 많은 수의 개발자들이 2.4까지 계속 문법 변화가 많았으니 이제 2.5부터는 문법은 바꾸지 말자하고 암묵적인 동의를 했음에도 불구하고, 이번에 예전에 수년동안 있었던 문법 변화보다 더 많은 변화가 들어가 버리니.. 파이썬 중도보수파들도 이제 파이썬의 변화에 반감을 느낄 것 같기도 합니다. 으흐~

Anonymous Block이 해결하려는 이슈를 소개해 드리자면, PEP에서 언급된 대로 “좋은 프로그래머들은 자주 나오는 코드를 재사용 가능한 함수로 분리”를 합니다. 그런데, 함수나 클래스로 쉽게 분리가 되는 경우도 많이 있지만, 어떤 경우에는 루틴의 앞부분과 끝부분, 오류처리부분과 루틴의 중간 중간이 드문드문 반복되는 패턴으로 자꾸 나오는 경우가 있습니다. 예를 들면, 공유 자원의 접근을 위한 뮤텍스라던지, DB 접근을 위한 트랜잭션 처리 블럭, HTML의 헤더/푸터나 table 앞뒤 장식, 임시 파일의 생성 등 수많은 경우가 해당이 될 수 있겠는데요. 이런 경우에는 콜백으로 빼서 클래스를 생성하자니 배보다 배꼽이 크게 되고, 그렇다고 매번 풀어쓰기에는 반복되는 로직을 자꾸 중복하게 되는 찝찝한 경우가 생기는데, 이런 경우를 극복하기 위해서 Anonymous Block (현재 파이썬 메일링에서는 그냥 “block”이라고 부르고 있습니다.)가 제안되었습니다.

즉, “block”에 진입하는 시점, 오류또는 정상 종료로 인한 이탈 시점, 반복을 하는 시점, 중간에 루프의 인자가 약간 바뀌는 시점 같은 것들을 기존의 문법인 제너레이터를 확장한 것과 짬뽕을 해서 멋지게 만들어 보자는 것이 요점입니다. 2.3부터 지원되고 있는 제너레이터는 이미 상당히 다양한 용도에 사용할 수 있는 성공한 문법이지만, next 메쏘드에 인자를 전달할 수가 없어서, 상태 관리가 매우 힘들다는 점이나 try: finally 블럭이나 try: except 블럭을 yield와 걸쳐서 사용할 수 없어서, 자원의 정상적인 해제가 불가능하다는 점에서 아쉬움이 있었는데 이러한 문제점도 여기서 완전히 해결되었습니다.

현재 상태에서 PEP-340에서 변경하는 기본 statement 변화는 이런 것들이 있습니다.

• __next__ 메쏘드 신설: 기존의 이터레이터 프로토콜에서는 __next__가 아니라 next메쏘드를 쓰고 있었는데, 이 이름이 범용으로는 아무래도 맞지가 않았기에, __next__로 새로운 메쏘드를 신설하고, __next__에 이제 인자 1개가 None이 기본값인 옵셔널 인자로 들어갑니다.
• __exit__ 메쏘드 신설: 이터레이터 프로토콜에 자원 해제를 위한 메쏘드가 없어서, 그동안 lock 해제 같은 것이 매우 곤란했었는데, 그 경우를 위해서 예외 발생 여부에 상관없이 항상 호출되는 __exit__ 메쏘드를 새로 만듭니다.
• next() 빌트인 함수: i.__next__()라고 맨날 쓰기에는 너무 보기가 안 좋아서, next(i)로 사용할 수 있도록 빌트인 함수가 신설됩니다.
• for 루프 변경: for 루프의 정의가 변경됩니다. 아래의 인자 있는 continue나 탈출 함수 호출을 위한 정의 변경이고, 예전 사용법으로 쓰는 경우는 똑같습니다.
• continue 인자 추가: continue 키워드 뒤에 이제 인자를 붙일 수 있게 되었습니다. continue 키워드 뒤에 인자를 쓰는 경우에는 바깥에서 돌고 있는 for또는 “block” 블럭의 이터레이터에게 전달됩니다. 즉, for 루프의 본문과 이터레이터가 직접 통신이 가능하게 되었습니다.
• Anonymous block 추가: 아직 이름이 정해지지 않은 (아직 “block”이라고 부르고 있습니다.) 새로운 블럭 키워드가 추가됩니다. 이 키워드는 for과 유사한 목적으로 사용될 수도 있지만, 이터레이터 인자를 항상 대상으로 하고 있다는 점에서 좀 다릅니다. 자세한 설명은 아래에서..
• 제너레이터 예외 처리: 이제 제너레이터의 yield statement가 try: except 블럭 안에도 들어갈 수 있게 되었으며, try: finally 블럭 안에도 들어갈 수 있습니다.
• yield statement 리턴값: 제너레이터의 __next__로 들어오는 인자를 받기 위해서 이제 yield statement가 들어온 값을 리턴합니다.

대충 훑어봐도 엄청난 변화임이 확실히 느껴지는데, 이게 아직 확실히 정해진 것은 아니니 허어억~ 하고 미리 놀라실 필요는 없습니다. (나중에 들어가면 그때 놀라면;; -o-) Anonymous Block을 사용하는 예제로 가장 많이 나오는 DB 트랜잭션 처리 같은 경우에는 이렇게 됩니다.

그리고, 이제 yield가 리턴값을 갖을 수 있기 때문에 유사-클로져나 유사-코루틴을 이제 쓸 수가 있게 되었습니다. 예를 들어서, 이런 코드가..

흐흐.. 결국 껍데기 부분의 루틴 분리에 획기적인 개선을 가져올 수 있는 좋은 도구가 될 수 있을 만한 것 같이 보입니다. 여전히 수많은 이슈들과 특히 키워드 이름을 무엇으로 할 것인가 등의 많은 문제들이 남아있지만, 아무래도 파이썬 2.5에 들어가면 가장 멋있을 것 같은 기능임에는 틀림이 없군요. 🙂 문법 변화라는 점에서는 원래 예정과는 좀 다르게 간다는 점에서는 약간 찝찝한 감이 있긴 하지만.. 뭐 이제 류창우님의 말씀 대로.. 파이썬도 C++이 가던 길을 걷고 있는 건지도.. (먼산)

IRC에서 후배 nezy군이 C++의 &인자와 같은 참조에 의한 호출은 어떻게 하냐고 물어봐서, 오기로 한번 만들어 봤습니다. 안 될게 뭐 있어!

결과 값으로 “49 4″가 나옵니다. t와 r이 yay 함수에서 계산된 값으로 세팅된 것~ 🙂

(주의사항): 이 소스는 그냥 장난이지 실제로 이렇게 쓰시기를 추천하는 것은 아닙니다.;;;

(사진은 좀 생뚱맞지만 뱃지만 찍으니 썰렁해서 군번줄을 같이;;;)

용이사님이 PyCon DC2005에서 기념선물로 사다주신 뱃지. 🙂 파이썬 로고 치고는 상당히 멋있습니다. 흐흐 공식 로고로 써도 되겠다~ -O- 오늘 이사님께 PyCon 얘기를 무지 많이 전해 들었는데, 정말 흥미로왔던 행사임이 틀림없는 듯합니다. 아아 내년엔 저도 꼭 가서 세계의 파이썬 친구들을 모두 만나고 하하하하 웃어야겠네요~ 🙂 아쉬우나마 사진 구경이나…

그리고, 곧 4월말 쯤에, 작년에 좀 하다가 말은 파이썬마을 작은 세미나를 이어서 하기로 했습니다. 이번에는 참여 저변을 조금 넓히기 위해, 참가자 6~8명 정도의 주제가 다른 트랙 2개로 해서 뒷풀이는 같이 하는 방법으로 하면 좋을 것 같아서, 아무래도 그렇게 할 것 같네요~ 🙂 주제로는 요새 모르면 남의 소스보기가 힘들어진 메타클래스 프로그래밍과 입문자용 트랙으로 py2exe, win32all를 해 보면 어떨까 생각하고 있습니다~ 자세한 것은 곧 파이썬마을에.. ^^;