python

늘 열리던 워싱턴DC가 아닌 텍사스에서 열리는 PyCon 2006이 1주일 앞으로 다가왔습니다. 작년까지는 거의 항상 3월 중순에서 말 사이에 했지만, 올해는 2월에 하게 되었습니다.

간단하게 올해의 PyCon 하이라이트를 정리해 보자면,
올해의 키노트는 24일에 Plone 개발자들, 25일에는 귀도가 “파이썬의 현상태”에 대해, 26일에는 파이썬으로 된 프로그램 중에 가장 많은 엔드유저를 확보하고 있는 BitTorrent의 Bram Cohen씨가 하게 됩니다. 이 중에서, Cohen씨는 독특하게도 기조연설을 인터뷰 방식으로 하겠다고 하고 있어서, 참가자들이 미리 질문을 올려 놓으면 그에 대해 대답하고 덧붙이는 방법으로 하겠다고 합니다. 재미있을 것 같네요. 🙂

강연/연설 들은 상당히 많은 세션이 배정되어 있는데, 작년에 비해서 꽤 늘어난 것이 파이썬 개발자들의 수가 확실히 늘고 있는 느낌이 듭니다. 작년 PyCon과 OSCon에서 상당히 인기를 끌었던 IronPython 세션의 후속편도 준비되어 있는데, 이번에는 Hugunin씨의 implementation 세션 외에도 MS의 다른 직원의 .NET 스크립팅 발표도 있습니다. 그리고, 웹 프레임워크 계에서는 역시 TurboGears와 Django, Zope 모두 마련되어 있고, 23일에도 상당히 많은 시간이 배정돼 있어서 역시 열띤 토론과 스프린트가 있을 듯 합니다.
그리고, PyPy의 구조에 대한 세션, Stackless의 사례, reST, docutils 같은 늘 나오던 사람들도 나와 있고, 사업에 파이썬을 사용하는 것, 엠베디드에서의 활용 사례, 노키아 S60의 사례 같은 것에 대한 발표도 있습니다.

작년 대안언어축제에서도 했던 OST를 위해 공간이 마련되어 있는데, 작년 PyCon 사진을 보고 우루루 바닥에 앉아 얘기하는 것들을 부러워했었는데, 올해도 PyCon에서 재미있는 이야기가 많이 나올 것 같아서 참 아쉽게 되었네요. 🙂

이번에는 RVSP로 실황 중계도 있고 녹화도 할 예정이라고 하니까, 직접 참가하지 않더라도 현장의 상황을 볼 수 있어서 무척 좋을 것 같구요. 24일에는 모여서 보드게임도 한다고 합니다. 🙂 그리고 참가자들 중에서 워낙 유명한 사람이 많다보니, 키사이닝 파티가 아니라 북사이닝 파티를 할 수 있을 정도라고 하니까 참 부럽군요~

PyCon의 더 자세한 이야기는, 곧 PyCon에 참가하러 텍사스로 떠나시는 OSK의 이만용이사님께서 돌아오시면 파이썬마을 번개를 한번 해서 듣는 자리를 마련 하도록 하겠습니다~ ^^

얼마 전, 2.4에 들어온 itemgetter, attrgetter와 2.5에 들어온 partial과 비슷한 새로운 제안으로 methodcaller라는 obj.meth(*args, **kwds) 를 줄여쓸 수 있는 뭔가를 만들자고 제안이 올라왔었습니다.
그에 대한 대답으로, FreeBSD의 bikeshedding 만큼이나 Python-Dev에서는 전통적인 여러 사람이 별의 별 희한한 자기 입맛에 맞는 문법을 마구 올려놓고, 서로 여기저기 투표하기만 하고 결론이 안 나는 상황이 꽤 오랫동안 있었습니다. lambda 를 더 짧게 쓰는 방법을 만들자, 그런 것 자꾸 만들면 복잡하다 그냥 def 하자, def를 리턴하는 키워드로 만들어서 안에 집어넣자 등등.. 나올 수 있을 만한 얘기는 거의 다 나왔습니다.

이에 대한 귀도의 답변: Let’s just *keep* lambda — Python 3000에서 lambda와 함수형 프로그래밍 함수들을 빌트인에서 빼려는 계획을 귀도가 그동안 여러번 언급을 했었는데, 그냥 lambda를 유지하고 다른 문법 논의는 다들 수긍할 만한 대안이 안 나왔으니 앞으로는 얘기하지 말자는 결론을 올렸습니다.

그동안 귀도의 눈치를 보며 숨을 죽이고 있던, 한국언론식으로 부르자면 이른바 “원로”라고 부를 만한 사람들이 우루루 귀도의 이런 선언에 전적으로 찬성한다는 댓글을 마구 올렸습니다. 오늘의 교훈은 “이도 저도 아니면 그냥 원래대로 놔두자.” 정도 랄까요? -O-;;;

SDForum Python Meeting이라는 모임에서 PSF 멤버이자, ASF의 의장이기도 하며, 구글 직원이기도 한 Greg Stein에게 한 호기심 많은 파이썬 사용자가 인터뷰를 해서 정보를 마구 캐내어 왔습니다. (SDForum은 실리콘 밸리의 개발자들의 기술 사교모임 비슷한 것 같군요. 흐흐) 파이썬을 쓴다고 하기는 하고, 귀도를 데려가는 걸 봐서 뭔가 하는 것 같긴 한데, 구체적으로 어떻게 쓰는지는 베일에 싸여 있었던 것이 이제 명확히 드러났습니다!

글에 구체적으로 나와 있지만, 주요한 몇가지만 요약하자면,

• 구글은 주로 C++을 쓰기 때문에, C++ 코드를 SWIG으로 감싸서 쓰는 경우가 많고 점차 늘어나고 있다.
• 다른 언어간의 통신을 위해 자체적인 바이너리 기반 RPC 프로토콜이 있다.
• 구글 내부의 모든 파이썬 코드는 반드시 PEP-8을 따라야 하는데 인덴트는 2칸으로 하는 것이 차이가 있다.
• 구글의 빌드 시스템은 완전히 파이썬으로 돼 있고, 의존성 관리, 주기적 빌드 등 모든 것을 관리한다.
• RPM같은 내부 패키징 시스템이 있는데 파이썬으로 된 것이다.
• 서버 관리와 서버간 정적 데이터 전송 등에 파이썬을 쓴다. 물론 모니터링, 리포팅, 로그/분석 등도 파이썬이다.
• code.google.com과 Google Groups 등 일부는 프론트엔드 서비스까지도 파이썬으로 되어 있는 것도 있다.
• 구글에서는 파이썬을 어울리는 적소에 사용하고 있기 때문에, 파이썬의 속도가 문제되는 경우는 거의 없다. 퍼포먼스가 필요한 경우에는 C/C++라이브러리를 SWIG으로 긁어서 사용한다.

그 외에도 구글이 MySQL을 주로 사용하고 있는 이유가 무척 흥미로운데, 상용 DBMS를 쓰던 시절에 벤더에게 새로운 기능을 추가해달라고 요청했을 때 심지어 개발자 비용을 대겠다고 해도 거절을 당한 경험을 하고서는, 그 다음부터 오픈소스로 바꿨다고 합니다. 그리고, 오픈소스가 아님에도 불구하고 자바를 쓰는 이유는 워낙 좋은 자바 프로그래머 인력이 많기 때문에 어쩔 수 없이 그러는 것 같군요. 흐흐.;;
더 재미있는 것들이 많이 내용에 나와 있으니 관심 있는 분들은 읽어보세요~

자.. 이제 느려서 파이썬 아무데도 못 쓰겠다고 하는 사람? =3=3

(ganadist님의 append vs new를 보고 이유를 살펴보는 겸 해서 써 봅니다.)

위 소스 둘을 보면 결과적으로는 아래 소스가 40% 정도 빠르게 동작합니다. 그렇지만, 왜 그런지 파악하는 것은 VM 내부 구조에 대한 연습을 무척 많이 하지 않고서는 쉽게 알기가 힘듭니다. 우선은 비슷한 라인이기 때문에 t += []는 inplace_add에서 resize가 일어나지 않을까 하고, 뒤의 것에서는 리스트가 계속 생성되지 않을까 하는 생각이 먼저 듭니다.

그런데, 이런 것을 진짜로 분석해보려면 파이썬 프로파일러로 해보면 라인단위로 나와서 그다지 큰 도움이 안 되고, C 프로파일러로 해봐도 대부분 인터프리터 루프가 먹고 있다는 것 정도만 파악이 되고.. 흐흐.. 그래서, 파이썬 VM 구조를 잘 모를 때도 쓸 수 있는 좋은 방법을 하나 소개합니다. 표준 파이썬에 dis 라는 디스컴파일러 모듈이 있는데, dis.dis 함수를 쓰면 코드/함수를 디스어셈블해 줍니다. 그래서 저 프로그램을 적당히 함수로 만들어서 디스어셈블을 해 보면 주요 부분이 이렇게..

그러면 디스어셈블 결과만 대충 봐도 앞의 소스는 LOAD_GLOBAL을 쓰고 있고 뒤의 것은 안 쓴다는 것을 알 수 있습니다. LOAD_GLOBAL은 딕셔너리 검색이 최소 1번에서 나쁜 경우 3~5번까지도 일어날 수 있는 옵코드이기 때문에, 있고 없고가 굉장한 성능 차이를 줄 수 있다는 것을 알 수 있습니다. 그리고, 두번째 것은 INPLACE_ADD 없이 그냥 BUILD_LIST해서 저장해버린 반면에, 첫번째 것은 INPLACE_ADD가 중간에 들어 있기 때문에, LOAD_GLOBAL 없이도 복잡한 것을 눈치챌 수 있습니다.

오늘의 연습문제: LOAD_GLOBAL/STORE_GLOBAL 외에 LOAD_FAST/STORE_FAST를 쓰면 위와 같은 소스가 굉장히 빨라질 가능성이 있습니다. 어떻게 하면 LOAD_FAST를 쓰도록 유도할 수 있을까요! (힌트: _GLOBAL은 딕셔너리 서치가 일어나고, _FAST는 미리 할당된 슬랏에서 인덱스로 바로 가져옵니다.)

2000년대 초반, Zope와 PSP, Webware for Python, mod_snake, PMZ 등 수많은 웹 프레임워크들이 쏟아져 나와서 경쟁적으로 독특한 방식으로 마구 내놓았습니다.
당시에는 현재의 Ruby on Rails나 Jakarta같은 것들이 압도적인 우위를 보이던 시절이 아니었습니다. 그러다보니 어정쩡하게 고만고만한 프레임워크가 너무 많이 나왔고, Zope 같이 너무 이질적이거나 현실적으로 투입하기가 쉽지가 않은 것에서 파생된 프레임워크들에 눌려서 별 진전이 없었던 것이 사실입니다.

최근, Ruby on Rails의 영향으로 django와 TurboGears가 아주 빠른 속도로 개발되면서 저변을 넓히고 있어서, 파이썬계에 두 번째의 웹 프레임워크 부흥기가 돌아왔습니다.

이에 대해서, 귀도의 컬럼인 All Things Pythonic에 글이 올라왔습니다. 귀도는 평생 웹에는 관심도 없을 것 같더니, Cheetah도 한번 해 보고 하는군요 🙂
Cheetah와 django의 템플릿 엔진을 보고서는 django의 우세라는 의견을 보였습니다. API가 우아하고 사용자에게 훨씬 친절하다고 하는군요.

현재 파이썬계의 가장 큰 프레임워크 양대 축인 Zope와 Twisted에 대한 의견도 끝에 붙였는데,
요즘의 프레임워크들은 똑같은 목적에 대해서 여러 개를 자기가
마음에 드는대로 섞어서 쓸 수 있다는 점을 특히 좋아한다고 합니다. TurboGears의 경우에도 템플릿으로 kids를 기본적으로 쓰지만, Cheetah를 쓸 수도 있고, 접속 계층은 특히 마음대로 선택해서 넣을 수 있다는 점에서 사용자가 자기 취향에 맞게 쓸 수 있다는 점을 좋아하는 듯 하군요. (원문의 뜻을 잘못 읽은 것을 서상현씨의 지적에 따라서 고침)

저는 파이썬 웹 프레임워크로는 Zope와 albatross, TurboGears, quixote를 해 봤는데, 다들 와 멋있다 싶긴 한데 정말로 같은 언어갖고 만든게 우쭈케 이렇게 다들 다르게 만들었나 하는 생각이 들면서, 혼란스럽다 웹 안 해야지 하는 생각만이 들었는데 흐흐. 앞으로는 서로 호환되는 여러가지 베이스 라이브러리를 기반으로 해서 다른 것들이라도 섞어 쓸 수 있는 그런 방향으로 가면 좋을 것 같네요.

대중적인 언어들이라면 요즘 누구나 FFI (Foreign Function Interface)를 갖고 있는 편입니다. C#(CLI)의 P/Invoke나 Haskell의 ffi같이, C언어 중심으로 이루어진 세상에 적응을 하려면
아무래도 꼭 필요하다고 볼 수 있겠지요~
그런 역할을 하고 있던게, 파이썬에서는 바로
ctypes인데,
그동안 많은 사용자들이 ctypes로 가려운 부분을 긁어가며
잘 쓰고 있었지만, 파이썬 소스코드만 짜서는 절대로 세그폴트가
나서는 안 된다는 귀도의 철학때문에 표준 파이썬에는 들어오지
못하고 있었습니다.

그러던 와중, ctypes개발자인 토머스가 다시 메일링 리스트에
용기를 내어 제안을 했고, 귀도가 이제 많이 성격이 온화해져서
마음이 완전히 편하지는 않지만, 그런대로 찬성이라는 의견을
올리면서, 드디어 2.5에서는 ctypes가 들어올 확률이 매우 높아졌습니다. 🙂

그런데, ctypes 안에 포함되어 있는 크로스플랫폼 ffi 라이브러리인
libffi가
gcc 안에서 automake를 쓰는 바람에, libffi 자체는 X11 라이선스임에도 불구하고, 빌드 스크립트들이 일부 GPL이 포함되어 있는 바람에 파이썬에 들어오게 되면 다른 파이썬 코드들이 GPL 영향을 받게 된다는 우려들이 나오면서 다들 라이선스 해석하느라 공황 상태에 들어갔습니다.

가장 큰 이슈는 automake가 생성해주는 aclocal.m4에 GPL 코드가 와장창 들어있어서, 그 부분을 어떻게든 제거를 하는 것이었습니다. 다들 automake는 결과 코드에 대해서는 라이선스 제한이 없다 있다고 싸우고 있었는데, 마틴이 그냥 빌드 도구를 우리가 따로 만들어서 쓰면 되지 않겠느냐고 해서, 그냥 설날기념으로 한번 automake를 제거하고 distutils에서 직접 빌드를 하도록 ctypes 패치를 해 봤습니다. 🙂

libffi가 생각보다 굉장히 간단한 라이브러리라 빌드과정이 복잡한 것은 전혀 없었고, configure 스크립트에서 보내주는 변수를 쓰기 위해서 fficonfig.py.in 이라는 템플릿을 autoconf에서 처리해주도록 해서 그걸 distutils쪽 스크립트에서 execfile해서 처리를 했습니다. 해놓고 나니 소스도 거의 1MB 줄고 좋네요~ 곧 ctypes가 들어갈 수 있기를 기원해 봅니다. -O-

http://www.amk.ca/diary/2006/01/pycon_keynotes_announced

어제 Zope 3.2 최종판이 릴리스 됐습니다. 그동안 Zope3이 계속 X3라는 이름을 달고 나왔었는데, 이번에 처음으로 안정 버전이라는 뜻으로 X를 떼고 그냥 Zope 3.2로 나왔습니다. 이는 곧 Zope 2보다 Zope 3을 앞으로 쭉 안정 버전으로 밀겠다는 뜻인데, 이미 Zope 4도 개발 중인 것 같군요.

Zope 3는 Zope 2의 경험을 토대로 해서 바닥부터 새로 만든 것인데다가 디자인 자체를 굉장히 수정한 탓에, Zope 2와 프러덕트가 거의 호환되지 않습니다. 따라서, Zope 2용으로 나왔던 COREBlog같은 프로그램들은 전혀 사용이 불가능하고 별도의 포팅이 필요하다고 합니다.
Zope 2는 앞으로 유지보수 수준의 릴리스만 하고, Zope 3이 쭉 유지될 것이라고 하니, 뭔가 Zope 2를 쓰던 사이트들은 마음의 준비를 해야할 때가 왔군요. ;;

Zope 3에 대한 상세한 정보는 Zope 3 개발 프로젝트 홈페이지에서 볼 수 있습니다.