python

거의 3년간의 개발 기간을 거친Zope X3가 드디어 릴리스 됐습니다! 구경을 약간 해 보니, Zope X3는 인터페이스 상에서 엄청난 변화가 있어서, 관리 화면이 완전히 바뀌어서 CMF처럼 일반 화면이랑 구분이 딱히 안 되게 되었는데, 한달 전쯤에 subversion에서 받은 것은 엄청 자주 익셉션이 떴었는데.. 요즘은 괜찮을라나 모르겠군용~독특한 점은 Wiki가 아예 디폴트로 들어있어서 위키 페이지를 기본으로 쓸 수 있는데, ZWiki보다 더 간단한 녀석이라;; -O-

아직은 Zope X3를 지원하는 프러덕트들이 거의 없어서, 금방 도입하기는 좀 힘들지만, 이번에 멋지게 변신을 완료 했으니 기대가 됩니다~ +_+

대망의 파이썬 2.4 첫 베타 릴리스인 2.4b1이 한국시간으로는 오늘 자정 12시에 릴리스 되었습니다. 2.4b1 부터는 이제 베타 릴리스라서, 기능의 추가나 기존 기능의 작동 방식 변경이 없고, 버그나 외부 인터페이스를 바꾸지 않는 향상, 명백한 결함에 대해서만 수정이 가해지게 됩니다. 2.4b1은 거의 1달 반만에 나온만큼 2.4a3에서 많이 바뀌었는데요, 대충 이런 것들이 바뀌었습니다.

• lukem씨가 수개월동안 패치를 업데이트해 왔던 재시작 가능 시그널 문제가 해결되었습니다.

• -m 명령행 옵션을 줘서 뒤에 모듈 이름만 주면 sys.path에서 찾아서 실행하는 기능이 추가되었습니다. (논란이 많았지만 결국은 추가 됐습니다. 흐흐;)

• 바이트코드 옵티마이저가 터플 묶음을 단체로 상수로 취급합니다.

• 새로운 subprocess 모듈이 추가되었습니다. 이 모듈은 os.system이나 os.popen의 느리고 복잡한 버전인데, viewcvs에 들어있는 popen.py와 비슷하게 구현되어있지만 좀 더 포터블하고 복잡하게 되어있습니다.

• re.findall re.finditer도 다른 re모듈 함수들처럼 플래그를 받을 수 있도록 바뀌었습니다.

• UTF-8과 UTF-16 내장 스트림 코덱들이 이제 완전한 stateful 상태로 동작할 수 있게 되었습니다. stateful코덱이 별도로 C로 구현된 것이 들어간 것인데, 다른 것들은 여전히 안 고쳐졌기 때문에, 멀티바이트 stateful 인코딩 중에 cjkcodecs에서 지원하는 것이나 utf-8, utf-16이 아닌 것들은 여전히 stateful 디코딩이 지원되지 않습니다. (뭐가 있는지는 안 찾아봐서;;)

• httplib이 IPv6를 지원합니다.

• DarwinPorts를 위해 /opt/local 을 prefix로 쓰는 라이브러리들을 인식하게 되었습니다.

저는 이제 마비노기도 끊었으니까 (;;) 다시 재미있는 파이썬질로 돌아가야겠습니다. 이히 ^^

1987년에 나온 IEEE/ANSI 표준인 IEEE854 기수법 독립적 부동소수점 연산 (Radix-independent Floating-Point Arithmentic)을 구현한 decimal 모듈은 파이썬 2.4에 들어온 모듈 중에 단연 가장 많은 관심을 받고 있고 기대가 되는 모듈입니다. 웹에서 찾아 보니까 IEEE854가 생각보다 많은 곳에서 이미 지원되고 있었는데 GNU libc에서도 몇개가 검색이 되는 걸로 봐서는 GNU libc에서도 지원이 되고 있는 것 같이 보입니다. (FreeBSD에서는 아직..)

이미 수학 연산을 많이 하시는 분이면 아시겠지만 저는 처음 들었는데, IEEE854는 IEEE754의 보완한 미래형 판(이라고 하기엔 좀 나온지 오래된;)이라고 할 수 있는데, IEEE854 스펙을 모두 지원하면 IEEE754도 지원할 수 있으니 수퍼셋이라고 봐도 될 듯 합니다. IEEE854-1987 표준은 스펙이 아주 간단히 나와있는데, 주요 특징으로는 다음과 같은 것이 있습니다.

• 2진법, 10진법 지원

• 연산되면 예외를 발생시키는 Signaling NaN과 그냥 NaN으로 만들어 버리는 Quite NaN 지원

• 정밀도 아래의 값을 다룰 방식 (올림, 내림, 반올림, 반내림 등등)

• 예외 처리

• 트랩 핸들러

사실 IEEE754는 구체적으로 본 적이 없어서 트랩 핸들러 같은 것까지 지원이 되는지는 잘 모르겠지만, 하여간 정말 멋지긴 합니다. 흐흐 그동안 파이썬에서 0.3+0.3했는데 왜 0.6이 안 되나요 하는 질문을 하면 “아이고 그건 원래 그런거예요.” 하는 뻘쭘하기가 그지 없는 그런 말로 대답을 해 줘야 했는데, (CP4E를 표방하는 언어가 2진법으로 소수쓰는 방법까지 이해를 하라는 건 –;) 하여간 IEEE854의 10진법 표기를 쓰게 되면 프로그래머나 비프로그래머 모두 쉽게 이해할 수 있는 0.3+0.3=0.6이 되는 즐거운 세상이 올 것 같군용.

파이썬에서는 IBM에서 Rexx언어를 위해 만든 범용 10진 연산 스펙을 기준으로 해서 구현이 되어있는데, 순수 파이썬으로 무려 3천라인이 넘는 구현이 되어있습니다;; 앞으로는 아무래도 파이썬 2.5나 2.6에서 set이 그랬던 것처럼 빌트인 타입으로 들어오게 될 것 같은데, 제 욕심으로는 아무래도 파이썬 3k에서는 스트링은 모두 유니코드로, 숫자형은 모두 Decimal와 int를 통합한 형태로 됐으면 하는 바람입니다. 0.3+0.3이 0.6이 되는 그 세상을 위해 –;;

얼마전에 AMK가 개인 블로그에 올린 파이썬 미래를 향해라는 글이 요즘 이슈로 떠오르고 있습니다.

주요 논지로는 앞으로 계속 늘어가는 여러 기반의 써드파티 파이썬 구현들 (Jython, PyPy, IronPython, Parrot 등등)과의 평화적인 공존과 CPython의 한계성을 고려하면, 앞으로 파이썬 언어 자체의 변화를 최소화하고 표준 라이브러리를 견고하게 하고 보완하는 것에 주력하자는 것입니다. 현재 파이썬 표준 라이브러리는 대충 보면 아주 많고 잘 돌아가는 것처럼 보이기는 하지만, 사실은 메인테인 안 되는 라이브러리도 산적해 있고, 숨어있는 구조적 버그도 꽤 많은 편이라 문제가 있긴 있습니다. 그리고, .NET이나 Java, Perl같은 표준 라이브러리를 위한 모듈 네임 스페이스가 없어서, 표준 모듈로 구분하는 것이 힘들다는 문제도 있고, 여러 가지를 지적하고 있군요. 흐흐 역시 혼자 느끼는 것은 아닌가 봅니다. +_+

또한, CPython은 크로스 랭기지 VM들의 유행, GIL로 인한 SMP 효율성, 써드파티 구현의 대거 등장 등등 여러 문제로 인해서 5년 안에 아무래도 버리게 되지 않을까 하는데, 저도 .NET이랑 Parrot을 보고서는 CPython은 아무래도 3~4년 넘게 가기 힘들겠다 생각을 하고 있었기는 합니다. 크로스 랭기지의 막강함은.. -o-

이 주제에 대한 토론 중에 rhettinger가 파이썬 언어 자체에서도 앞으로 변경되어야 하는 사항에 대해서 얘기를 해 주었는데, 그 중에 빌트인 타입으로 decimal이 들어가면 좋겠다고 그래서 깜짝 놀랐습니다. 흐흐

지난 7월에 있었던 OSCON에서 직선적인 파이썬 전도사인 폴 그레이엄이 “파이썬 프로그래머는 자바 프로그래머들보다 똑똑(smart)하다.”라고 하는 바람에 현장에서는 박수를 치고 난리가 났지만, 뒤에서 자바 프로그래머들에게 엄청난 공격을 받은 적이 있습니다. 평소에 폴이 늘 하는 스타일의 짓이긴 했지만. 자기 홈페이지에 왜 그렇게 말했는지에 대한 해명이 올라왔군요.

주요 내용으로는, 자바 프로그래머들은 보통 밥먹고 살기 위해서 또는 학교에서 시켜서 시작하는 경우가 많다. 그러나 파이썬 프로그래머들은 파이썬만 갖고는 밥먹고 살 방법도 묘연하고, 학교에서 시키는 경우도 드물기 때문에, 사실상 파이썬 프로그래머들이 자바 프로그래머들에 비해서는 순전히 자기 만족을 위해서 파이썬을 시작한 경우가 많다. 물론, 그런 사람들도 밥먹고 살기 위한 C나 Java, C#, VB등의 언어를 이미 알고 있는 경우가 많기 때문에, 파이썬 프로그래머들은 평균적으로 자바 프로그래머들보다 똑똑하다고 볼 수 있다. 라는 논리입니다. 흐흐흐..

폴은 그래서 “Python Paradox”라고 이름을 붙인 이런 역설을 하나 소개합니다. “소프트웨어를 비교적 덜 알려진(소수의; esoteric) 언어로 개발하는 회사는 보통 더 나은 프로그래머를 고용할 수 있는 가능성이 높다. 왜냐하면 거기에 고용된 사람들은 그런 언어를 익힐 정도로 열의가 있는 사람들이기 때문이다.” 전에 “설득의 심리학”에 나왔던 역설과 비슷한 말이 됩니다. “좋은 일자리를 얻으려면, 사람들이 좋은 일자리를 얻기 위해 공부하는 언어가 아닌 것을 공부하는 것이 좋다.” 구글도 자바 프로그래머를 뽑으면서 파이썬도 아는 사람을 찾는다는군요.

므흐흐.. 사실은 리눅스코리아도 파이썬을 할 줄 아는 php프로그래머, C프로그래머를 줄곧 몇년간 뽑고 있는데, 국내엔 파이썬 프로그래머 자체가 워낙 적어서 으흐~;

“밥먹고 살려면 밥먹고 사는 것에 관심이 없는 척해야 한다.” -O-

Zope도 아니면서 Zope에 근접하는 엄청난 속도를 자랑하는 TwistedWeb을 실제로 적용한 사업용 사이트가 나타났습니다. +_+ TwistedWeb은 참 멋지긴 하지만, 100% TwistedWeb기반으로 작동하고 있는 CIA를 봤을 때 어떻게 이렇게 느릴 수가 있는가! 하고 생각을 하고 있었는데, CIA가 아무래도 하드웨어가 안 좋았나 봅니다. ;

Superleage 사이트는 바로 그 느리기로 하면 TwistedWeb 못지않게 유명한 PostgreSQL을 사용하고 있는데, 그런대로, 복잡한 DB 작업이 일어날 만한 페이지들도 무난히 나오고 있습니다. 신기하군요. 역시 잘 만들면 되나봅니다. (또는 아직 방문자가 없거나;;)

실제로 이렇게 적용한 사이트를 보고 나니, 괜히 지금 하고 있는 실패한 D모 프로젝트를 TwistedWeb으로 했으면 좋았을 거라고 생각을 해 보게 되는군요. =.= 흐흑..

Boo에 이어 또 다른 .NET 기반의 파이썬 비슷한 언어가 발표되었습니다. 얼마전 Prothon도 .NET 기반으로 옮긴다고 했다가, Guido가 눈물로 애원해서 CPython기반에 확장으로 옮기는 것으로 됐는데, 요즘 .NET 기반 언어들이 정말 많이 나오는 걸 봐서 확실히 이제 슬슬 붐이..

Boo는 파이썬을 기반으로 자기 나름대로 컴팩트한 언어를 새로 구축했는데, 보통 많은 사람들이 요청하는 for … as나 print의 내장함수화, using: (with:) 구문 같은 걸 도입하고 있다는 점에서 신선합니다. 그런데, 이번에 새로 나온 PyCs의 경우에는 C# 흉내를 내겠다고 하고 있는데, 기본적인 문법틀은 Prothon의 것을 따오고 있습니다. 아무래도 Prothon이 .NET으로 옮기겠다고 했다가 말아서 그 영향으로 분리가 된 것 같은데, Prothon외에도 Microsoft의 C-Omega의 컨커런시 모델이나 내장 XML/SQL 지원을 참조해서 디자인하겠다고 하니, 뭔가 웹 스크립트용으로 갱장히 간편한 언어가 나올 듯 합니다. 흐흐.

점점 파이썬 관련 언어의 구현이 많아지고 있어서 앞으로 Python 3000이 나오면, CPython이 널리 쓰이는 유일한 파이썬 구현이 아니게 될지도~~

오늘 파이썬 버그 메일링 리스트를 보다가 깜짝 놀랐습니다. Submitter: rivest라고 되어있어서 으흠. Rivest도 그렇게 영 없는 성은 아니구나~ 하고 생각을 하고 있었는데. 아니.. 이름이 Ronald인 것입니다. 오호 이름까지 같은 사람이 있군! 하고.. 버그 내용을 살펴보고 있었는데.. 헛~!!! 아니 밑에 메일이 mit.edu!! 그렇다면 이게 바로 그 진짜 Rivest씨 아닌가! 아아.. 이런 사람들은 그냥 펜 잡고 신선 놀음만 하는 줄 알았더니, 파이썬 쓰다가 파이썬 버그 보고를 “직접”할 정도의 실무 열의를 갖고 있다니 정말 감동입니다. 주르륵 주르륵. 이제 앞으로 SHA1 안 쓰고 MD5만 써야겠습니다. -O-;;;

얼마전에 Python 3000에 대한 대략적인 것을 이제 슬슬 정해 보자고 토론 되었던 대로, 오늘 PEP3000이 등록되었습니다. amk와 brett이 지난 PyCon때, 얼마전 토론, 위키에서 나온 내용 등을 토대로 정리한 것인데 처음 듣는 것도 몇개 있어서 상당히 흥미롭군요. 아직 나올 날은 멀었지만 무척 세련되어 질 것 같아서 설렙니다. 주요 차이점들 (아직 그냥 예정이고 결정된 것은 아님) 중 제가 재미있다고 생각한 것들은 이렇습니다.

• 문자열은 이제 유니코드!: 엊그제 블로그에서 얘기했던 대로, 이제 바이트 타입을 따로 신설하고, 자바나 C#처럼 기본 문자열 타입을 유니코드로 가 버릴 듯합니다. 이로써 세련된 다국어 지원을 좀 더 완벽히 지원할 수 있을 것 같네요. ^^;

• long과 int의 완전 통합: 현재는 int와 long이 따로따로 있으면서 int가 상황에 따라 long으로 업그레이드 되는 어정쩡한 통합 구조를 택하고 있는데, Python 3000에서는 int와 long이 같은 타입으로 값에 따라 내부 표현을 정하며 외부 인터페이스는 완전히 동일한 방법을 택할 듯 합니다.

• 정적 타입 인자의 지원: 효율적인 최적화나 입력값의 제한 등 여러가지 정적 타입인자의 장점을 선택적으로 취하기 위해서, 필요한 경우 정적 타입을 쓸 수 있도록 합니다.

• 모든 클래스가 new style: 현재 Exception을 비롯한 대부분의 라이브러리에서 구식 클래스를 쓰고 있는데, Python 3000에서는 완전히 모두 new style class로 바뀝니다.

• 이터레이터의 대거 도입: dict.keys(), dict.items(), range(), zip() 등을 비롯한 대부분의 리스트를 리턴하는 내장 타입, 내장 함수들이 이터레이터를 리턴하도록 바뀝니다.

• print, exec, lambda 키워드 소멸: print 키워드가 사라지고 write(), writeln()등의 내장 함수로 대체되며, exec키워드 대신 exec함수가 생기고, lambda는 그냥 없어집니다.

• 백쿼트 () 표현 소멸: 파이썬에서 제일 Perl스러운 부호 중의 하나인 가 없어집니다.

• 내장 함수들 대거 소멸: apply, buffer, callable, compile, coerce, input, intern, map, filter, raw_input, reduce, xrange 등 현재 다른 스타일로 대체되었거나 대체되는 중인 내장 함수들이 모두 사라집니다.

이 외에도 앞으로 10배는 더 많이 충격적인 내용이 들어가야 할 것 같은데~ 모두 좋은 아이디어를 생각해 봅시다 크흐흐;

요즘 파이썬계에서는 PEP318 펑션 데코레이터가 엄청난 태풍으로 몰아치고 지금은 다 싸우다 지쳐서 수그러드는 태세지만 여전히 결론은 안 나고 문법을 새로 도입할 때마다 겪는 진통을 톡톡히 겪고 있습니다.

그 와중에 두가지 문자열 처리 이슈가 띄엄띄엄 토론되고 있는데, 바로 “Decoding incomplete unicode”와 “adding a byte sequence type to Python”입니다. 전자는 StreamReader나 StreamWriter에서 현재 표준 UTF-8, UTF-7 코덱은 완결되지 않은 상태를 제대로 처리하지 못하고 있으며, CJKCodecs의 코덱들은 대충 파일이 끝나면 시퀀스도 끝났다고 보고 처리하고 있는데 이를 프로그램측에서 명시적으로 끝이다 아니다를 결정해 주는 API를 추가하자는 Walter의 제안으로 시작되었습니다. Walter의 제안에서는 패치도 나왔지만 API가 지나치게 복잡하고 Marc-Andre가 API가 변경되는 것에 강하게 반발하고 있어서 어떻게 될 지는 모르겠지만, 아무래도 필요하기는 할 것 같네요. CJKCodecs에서도 끝인가 아닌가 판단하는게 참 모호해서, EUC-JISX0213 코덱 같은 경우에는 호출 도중에 어디에서 짤리느냐에 따라 결과가 달라지기도 하는 문제가 있습니다 -O-

그 다음에 “adding a byte sequence type to Python”은 b”xxxx”라고 쓰면 바이트 시퀀스로 처리하고 문자열처럼 쓰지 말자 뭐 이런 내용인데, Java나 C#처럼 유니코드가 나온 이후에 나온 언어들은 대체로 다 채택하고 있는 byte와 char타입의 분리에 대한 내용입니다. 현재 파이썬에서는 “xxx”라고 쓰면 이게 싱글 바이트 시퀀스이면서 문자열을 겸하는데, 원래 싱글 바이트 시퀀스의 역할을 b”xxx” 표기법으로 바꿔버리고 “xxx”는 순수한 문자열 객체로 뭐 어쩌고 저쩌고 하자는 원래 제안이 올라왔었습니다. 그런데, 대충 토론의 결론은 이렇게 되면 하위호환성 문제가 되니까, Python 3000에서 “xxx”는 유니코드 타입으로 바꿔버리고 b”xxx”를 싱글 바이트 시퀀스로 쓰자는 쪽으로 결론이 났고 귀도가 이를 확인해 줬습니다. 그리고 물론 싱글 바이트 시퀀스 타입에서는 기존에 있던 str.lower이나 str.isalpha같은 문자열에서만 있는 메쏘드들이 다 사라질 것이라고 합니다. 현재 문자열은 뭐 영어 사용자들을 위한 문자열이나 다름이 없으니 Python 3000 아주 기대가 되는군요. 냉큼 바뀌면 좋겠습니다. ㅋㅋㅋ (그러나.. 그 기존에 문자열을 바이트 시퀀스로 쓰는 대부분의 코드들은 어찌 포팅할지 -ㅇ-)