OpenLook

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

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

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

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

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

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

늘 열리던 워싱턴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를 해 봤는데, 다들 와 멋있다 싶긴 한데 정말로 같은 언어갖고 만든게 우쭈케 이렇게 다들 다르게 만들었나 하는 생각이 들면서, 혼란스럽다 웹 안 해야지 하는 생각만이 들었는데 흐흐. 앞으로는 서로 호환되는 여러가지 베이스 라이브러리를 기반으로 해서 다른 것들이라도 섞어 쓸 수 있는 그런 방향으로 가면 좋을 것 같네요.