python

Python 2.3 라인의 새로운 버그픽스 버전인 2.3.1이 릴리즈되었습니다. 이번 2.3.1 릴리즈는 2.3이 발표된 직후 발견된 몇가지 치명적인 버그들과 숨어있던 메모리 누수를 많이 잡았습니다.

FreeBSD lang/python 의 업데이트는 지금 4.9 릴리즈를 위한 semi-frozen 상태이므로 업데이트가 어렵고, 한 1주일 안에 업데이트할 수 있을 것 같네요. 제 컴퓨터에서는 일단 test도 모두 성공하고 있습니다. (i386) 그런데, sparc64에서는 몇개 실패하고 amd64에서는 크래쉬나는 게 몇개 보이네요.

CJKPython은 어제 2.3.1-RC로 잠시 작업을 했는데, 내일 중으로 CJKPython 2.3.1을 릴리즈할 수 있을 듯 합니다.

이히히. 그동안 홈페이지가 그냥 기본 프로젝트 페이지였는데 KoreanCodecs와 그 일당들을 모두 BerliOS로 옮기면서 같은 스타일로 간단하게 홈페이지를 만들었습니다. 일본어 잘 하시는 분 있으시면 일본어 번역 좀 손봐주세용~~;;; 아 CJKPython뿐 아니라 IconvCodec과 CJKCodecs HangulModule도 같이 옮겼습니다. 이제 소스포지는 사용하지 않아요 ~.~

CJKPython 새 홈페이지: http://cjkpython.berlios.de/

윈도우용 한/중/일 전문 파이썬 개정 배포본인 CJKPython 2.3.1a1을 릴리즈했습니다. 이번 버전에서는 전의 릴리즈에서 실험적으로 채택했던 wxPython과 Boa Constructor를 라이센스 문제로 제거했고, 다시 파이썬 표준 배포본처럼 Tkinter와 IDLE를 넣었습니다. 그리고, 인스톨시에 바이트 코드를 컴파일하기 때문에, 시스템관리자가 아니더라도 빠르게 파이썬 프로그램들을 실행할 수 있게 하였습니다. 전의 버전에서는 사실 SJIS 패치가 안 들어갔었는데 이번엔 빠짐없이 다 넣었습니다.

윈도우에서 파이썬 쓰시는 분들은 한 번쯤 테스트해 봐주세요. 다운로드는 CJKPython 를..

얼마전 OnLamp에 Guido van Rossum과의 인터뷰가 올라왔습니다. 얼마전에 귀도가 Zope를 떠나서 다른 회사로 간다고 발표한 것도 있고, 2.3과 2.3.1얘기도 있고 해서 인터뷰 내용이 아주 재미있는 게 많네요 그동안 파이썬 문법이 계속 복잡해지면서(관점에 따라..) CP4E를 포기한 것인가! 하고 주장하는 사람도 있었는데, 아직 Guido는 CP4E가 어느 정도는 지금도 말이 된다는 입장이군요 으흐흐;;

ActiveState에서 만든 구리구리한 Python.NET 말고 Zope에서 만들고 있던 PythonNet이 Preview 2가 발표가 됐군요~. 아직까지는 MS.NET CLR하고만 제대로 돌아가지만, Mono로도 곧 되지 않을까 싶습니다. 흐흐

타볼을 풀어보면 빌드하기는 좀 아리송 하고 (뭔가 싸인을 하려면 인증서가 있어야 한다는데, 배포는 같이 안 하는군요) 바이너리가 들어있어서 그걸로 실행해 보면 됩니다.

짠 실행해 보면

흐흐 Jython 처럼 뭐 플랫폼이 바뀌는 것은 아니고, 그냥 일반 CPython과 CLR의 중간 연결고리만 만들어 놓은 녀석이라, 플랫폼은 그냥 네이티브로 나옵니다. 그리고, 파이썬 바이트 코드들은 .NET 어셈블리로 바뀌어서 실행되는 게 아니라, 전부 CPython VM이 실행하고 중간 데이터 교환만 PythonNet이 담당해서 CLR에게 전해지게 됩니다.

WinForm도 벌써부터 잘 되네요 흐흐..

이미 해본 분들은 아시다시피 ~.~, 파이썬 2.3에서는 –enable-shared를 주면 공유 라이브러리로 사용이 가능하도록 돼서, libpython2.3.so가 1메가짜리가 나오고 python은 3천 바이트짜리가 나옵니다.

그래서, 이야 멋지다 하고 메모리 절약에 도움이 되지 않을까 하는 생각에, FreeBSD포트 lang/python 에는 덥썩 shared를 디폴트로 해 버렸는데, 다행히도 python-dev 메일링에 누가 “왜 –enable-shared가 디폴트가 아닌가요”하는 질문에 Martin v. Löwis가 좋은 대답을 해 주어서, 덕분에 잘못 알고 있었던 것을 바로 잡게 되었습니다. 으흐흐 (다들 알던 것인가;;)

웬지 공유 안 할 것 같아 보였던, static 바이너리도 inode가 같은 경우에는, text 이미지를 메모리에서 모두 공유한다는군요 (두둥!) ~.~;;

Löwis의 가르침(!)을 요약하면..

파이썬 바이너리가 1개만 있으면, 걔네들은 모두 공유라이브러리 만큼 전부 메모리나 디스크 공간을 공유한다. 그런데, 거의 대부분의 파이썬 애플리케이션들이 파이썬 바이너리를 따로 쓰는 게 아니기 때문에, 대부분의 파이썬 애플리케이션들은 실행 파일 이미지를 메모리에서 공유한다고 볼 수 있다. 특별한 예외라면 mod_python이 있는데, mod_python은 아파치 바이너리를 통해서 공유돼서, 다른 파이썬 바이너리와는 공유하지 않지만, 아파치 바이너리들 끼리 공유해서 같은 효과를 얻는다.

공유 라이브러리를 유지하는 것은 상당한 관리상 문제점이 따른다. 어떤 경우에는 인스톨이 제대로 안 될 수도 있고, 공유라이브러리 링커에 따라 못 찾게 될 수도 있다.

공유 라이브러리를 사용하면, 시작하는 시간이 길어진다. 또한, ld.so에 디렉토리가 몇 개 더 추가되어야 하고, 빌트인 모듈로 컴파일되지 않은 파이썬 모듈까지 모두 공유라이브러리 패스에 들어가야 한다. (퍼키 주: 이 부분은 적어도 FreeBSD에서는 사실이 아닙니다. FreeBSD에서는 그냥 dlopen(3)으로 절대경로찾도록 되기 때문에, 정적 컴파일한 것이나 같습니다.)

공유 라이브러리를 사용하면, 실행 시 효율성이 떨어진다. PIC (Position-Independent-Code)는 일반적으로 non-PIC 바이너리보다 최적화에서 불리하다. (블루님 주: 현실적으로는 거의 차이가 없다고 합니다. 😉

공유 라이브러리를 들고 있으면, 관리 비용이 더 많이 든다. 컴파일러, 링커, 다이내믹 링커 등등 거의 모든 개발 툴에서 기존에 없었던 문제가 발생될 수 있고, 이에 대해서 일일이 고려해야한다.

흐흐흐. 그래서, FreeBSD의 lang/python 포트도 별도의 공유 라이브러리 포트를 분리해 내고, 정적 컴파일로 다시 돌리려고 합니다. 만세 \(-.-)/

(Martin v. Löwis의 원문은 http://mail.python.org/pipermail/python-dev/2003-August/037472.html)

지난 번에 string repr과 string print를 로켈에 맞게 수정한 버젼이 pickle같은 몇 가지 곳에서 문제가 발견되어 CVS에 들어갔다가 빠졌는데, 새로운 방법을 여러 모로 생각해 봤지만, 적당한 방법이 생각이 안 나서, 결국은 type object에 tp_richrepr 이라는 메쏘드를 새로 만드는 방법을 한 번 생각해 봤습니다.

파이썬에서 오브젝트가 출력되는 방법은 두 가지인데,

• PyFile_WriteObject에서 출력하는 오브젝트가 진짜 파일인 경우에는 PyObject_Print로 직접 FILE *fp에다가 출력. PyObject_Print는 재귀적 탐색을 해서 String의 경우에는 PyString_Print가 내부 함수인 string_print를 호출해서 최종적으로 출력하는 데, 이 때에 flags에 Py_PRINT_RAW가 세팅되는 경우에는 그냥 fwrite를 하기 때문에 한글이 제대로 나오는데, 0인 경우에는 한글이 모두 이스케이프되어 버림.

• PyFile_WriteObject에서 출력하는 오브젝트가 StringIO같은 가짜 파일인 경우에는 PyObject_Repr로 일단 String으로 만든 뒤에 그 녀석을 인자로 해서 출력 오브젝트의 write를 호출.

여기서, 첫번째 방법으로 출력이 되는 경우에는 그다지 어렵지가 않은 것이, Py_PRINT_RICH라는 플래그를 하나 만들어 줘서, 그 녀석을 계속 끝의 flags에 달아 다니다가, PyString_Print와 PyUnicode_Print에서만 적당히 처리해서 뿌려주면 될 것 같습니다.

그런데, 이제 두번째 경우에는 repr()이 호출되어서 PyObject_Repr에 들어온 것인지, 출력하려고 PyObject_Repr에 들어온 것인지 하위 오브젝트들에게 전달해 줄 수 있는 방법이 전혀 없기 때문에, 결국은 새로 오브젝트 프로토콜 메쏘드를 하나 만들어 주는 수 밖에 없는 걸로 보입니다. 그래서, 결국 typedef PyObject *(*richreprfunc)(PyObject *v, const char *encoding); 타입으로 하나 만들어서 typeobject의 제일 끝에 추가하고 PyObject_RichRepr을 PyFile_WriteObject에서 사용하도록 하려고 생각하고 있습니다.

아직은 가능성을 위해서 이것 저것 테스트해 보고 있구요 ~.~; 우선, CJKPython 2.3final에서 표준 2.3과 호환성을 유지하기 위해서는 타입 오브젝트의 크기가 변할 수 없기 때문에, SJIS 패치에서만 그냥 원래 일본식 repr을 쓰고 표준 타입에서는 sys.displayhook만 교체하는 방법을 쓰려고 합니다.

파이썬 2.4에서는 다국어 문제가 말끔히 해결되었으면 좋겠네요. 혹시 좋은 아이디어 있으신 분들은 꼭 알려주세요~

Apple의 MacOS X 10.3 Panther의 출시에 맞추기 위해서 7월 31일 이전에 발표하기로 했던, Python 2.3이 활발히 진행 중입니다. 몇 가지 주된 이슈들을 정리하면..

• -Kthread 옵션이 실패하지 않는 문제: -Kthread를 지원하지 않고 C 컴파일러가 쓰레드 라이브러리를 별도로 요구하는 FreeBSD, NetBSD, MacOS X 같은 환경에서 5월부터 configure하면 -Kthread 테스트부분이 실패는 하지만, 실제로 gcc가 에러를 리턴하지 않아서 결국은 -Kthread가 없는데도 -Kthread를 써버리는 문제가 있었습니다. FreeBSD의 lang/python-devel 포트는 이에 대해서 로컬 패치을 쓰고 있었는데, Skip과 Martin이 열심히 이리저리 해본 후에, 딱히 -Kthread의 실패를 감지할 좋을 방법이 없어서, 그냥 따로 kthread 옵션을 플랫폼마다 configure에서 처리해 주기로 했습니다.

• Cygwin에서 쓰레드 문제로, 멎어버리는 현상: Cygwin의 sigmask의 구현의 자체 버그로 인한 것으로 밝혀졌으며, 그에 대한 대응 패치가 들어가서 해결되었습니다.

• BSDDB3가 윈도우와 리눅스에서 멎어버리는 현상: bsddb3가 쓰레드를 쓰는 프로그램에서 제법 불안한 것으로 실험되었습니다. 대부분의 경우 큰 문제는 없지만, 그래도 트랜잭션을 완전히 걸어주면, 웬만큼은 해결된다고 합니다.

• zipimport: zipimport가 zip앞에 쓸데없는 데이터가 섞여 있는 경우, zipfile모듈과는 달리 읽지 못하는 문제가 있다고 합니다. 그렇지만, 이미 파이썬 2.3이 RC상태이므로, 이것을 ‘기능’으로 처리할 것인지, ‘버그’로 처리해서 고칠 것인지 얘기가 있었는데, ‘버그’로 결정이 난 듯 해서, 지금 HEAD에는 고쳐져 있습니다.

• Mac: 이번 릴리즈를 서두르게 된 이유가 된 맥 환경에서도 인스톨러 문제를 비롯한 몇 가지 문제가 있었는데, 열혈 pyobjc 멤버들과 Jack의 노력으로 대부분이 해결 되었습니다.

• 브랜칭: FreeBSD와는 달리, Python은 베타와 RC를 별도 릴리즈 엔지니어링 브랜치에서 하지 않고, HEAD에서 합니다. 따라서, 브랜칭은 Python 2.3 final이 나오고나서 HEAD 브랜치가 2.4가 되고, 2.3은 23-maint 브랜치로 들어가게 됩니다.

잘 안 알려진 (에.. 적어도 제 주위엔;;) 유용한 파이썬 디버깅 팁을 하나 소개합니다~

보통 파이썬 스크립트 테스트할 때 스크립트를 실행해서 익셉션이 발생하면 트레이스백을 보고 대충 상황을 추측하거나 예외난 부분 근처에 print를 잔뜩 써서 해결하게 됩니당. (디버거로 들어가기 힘든 부분에 들어갈 때..)

근뎅, 파이썬의 -i 옵션을 쓰면 요 문제를 바로 깔끔하게 해결할 수 있습니.. 으흐흐흐. 꺄아~* 다음 스크립트는 dict.get을 쓸 때 자주 발생하는 타입 에러 중 하나인뎅 봅시당~

하면 당연히 d에 ‘kitty’가 없기 때문에 int+None해서 타입에러가 납니다. 근데, 요게 무지 긴 프로그램에 들어 가고 막 코드가 흩어져 있으면 깨나 애를 먹일 수 있는데, 파이썬에 -i옵션을 주면 다음과 같이 익셉션이 나자마자 바로 인터프리터가 떠서 상황을 볼 수가 있게 됩니당.

으훗~ 물론 뭐 인터프리터니까 함수 몇 개 실행해 볼 수도.. 파이썬 2.3b2부터는 PYTHONINSPECT 환경변수를 아무꺼나로 지정해 주면, -i 옵션을 안 쓰고도 인터프리터를 띄울 수 있습니다.

오늘 python-dev 메일링에서 –without-pymalloc 옵션을 주면 malloc/free와 관련된 비표준 문제가 생긴다하는 어떤 사람의 질문에 대한 Guido의 답변에 대한 Tim의 답변이 흥미로웠습니다.

역시 같은 기능에 대해서 두가지 옵션이 안정적으로 제공되려면 덜 매력적인 옵션이 디폴트가 되고 더 멋진 옵션이 선택사항이 되어야, 코드가 깨지는 것을 그런대로 막을 수 있다는 생각이 듭니다. (소비자의 테스터화 작전 -O-;;)