python

지원님께서 드디어 PEP289를 구현한 패치를 소스포지에 올리셨습니다. 우와~ 제가 BNF ambiguity 해결하고서는 놀고 있었더니 먼저하시다니 =3 =33 크크.. 파이썬 정규 문법 구현 패치로는 한국인 최초이기에 지원님이 자랑스럽습니다. (괜히 친한 척 해본다;; )

몇가지 테스트해 보니까 PEP에 명시된 스펙은 모두 잘 되는 듯 합니다.

이야 정말로 PEP에서 보던 것 보다 훨씬 좋네요. 크크 패치를 리뷰한 다음에 빠른 시일 내에 커밋하도록 할 생각입니다. 지원님도 곧 파이썬 개발자로.. =3 =33

1달 전쯤에 있었던 python-dev에서 토론 중에 나왔던 바로 그 연산자를 받으면 전부 함수로 만들어버리는 걸 그냥 모듈로 한번 만들어 봤습니다. 사실은 operator모듈에 넣고 싶었지만, 선행 연산자에 변수가 있으면 발생하는 모호성이나 체이닝 콜 같은 게 너무 심각해서 표준에 넣었다가는 돌맞을 것 같아서 으흐~;;

devel/py-anonfunc 에서 Sources 클릭하면 타볼을 받을 수 있습니다.

간단하게 사용법은 설치하고 파이썬을 띄우면 빌트인에 X, Y, Z, anonfunc가 들어가 있는데, X는 첫번째 인자, Y는 두번째 인자, Z는 세번째 인자, anonfunc는 얘네들의 클래스입니다.

한/중/일 파이썬 유니코드 코덱인 CJKCodecs 1.0.3이 릴리즈되었습니다. 1월 3일 맞추느라 좀 서둘러서 -O-;; (사소한 것에 집착;;)

변경사항은 대부분 일본어 지원에 관한 것이라 한국어 관련 인코딩에서는 iso-2022-kr 코덱이 MSB세팅된 글자에 대해 에러내게 바뀌었다는 것 밖에 없습니다.

다운로드는 http://cjkpython.i18n.org/#CJKCodecs 입니다.

(_ _);

http://people.freebsd.org/~perky/cjkcodecs-1.0.3c1.tar.bz2

CJKCodecs 1.0.3 RC를 공개했습니다. 일본인들에게 리뷰를 요청했는데, 결과를 받아본 뒤에 1~2일 내에 정식 릴리즈를 할 예정입니다.

수정된 사항은:

• ISO-2022-JP 코덱들에서 JIS X 0208의 0x21/0x40이 원래 매핑이 되어있지 않던 것이, U+FF3C에 매핑되도록 바뀌었습니다.

• ISO-2022 코덱들이 JIS X 0208:1978 시퀀스를 인식하지 못하던 문제를 고쳤습니다.

• ISO-2022-JP{,-1,-3} 코덱은 이제 SI, SO를 사용하면 디코드 에러를 냅니다. (JapaneseCodecs 와의 호환성)

• EUC-JP, SHIFT-JIS 코덱에서 사용자 정의 구역(PUA) 지원을 제거했습니다. 실제로 일본인들은 이 구역을 안 쓴지 오래됐다는군요.

• ISO-2022 코덱들의 디코더에서 MSB가 세팅된 글자가 넘어오면 디코드 에러를 냅니다.

• ISO-2022-JP 코덱들이 이제 JIS X 0208:1997 시퀀스 (ESC & @ ESC $ B)를 지원합니다. RFC에 등록된 것은 아니지만, 실제로는 쓰인다기에..

• 진짜 ISO-2022-JP-EXT 코덱이 들어갔습니다. (ISO-2022-JP-1 + JIS X 0201 반각 카타카나 지원)

원래 파이썬에서 import 하면 모듈이 존재하는 곳을 맨 먼저 찾고, 표준 서치 패스를 찾게 되어있습니다. 그런데, 얼마 전 Raymond의 크리스마스 소원 목록에서 등장해서 엄청난 이슈를 일으키고 있는 명시적 상대 경로 임포트 (explicit relative import)가 이제 뭔가 대세가 되고 있군요.

중간에 문법과 구현 원리가 엄청 많이 제시되기는 했지만, 대충 지금까지의 의견 수렴은

• ‘.’를 기본 sys.path에서 뺌 (지역 디렉토리에서의 단순 임포트 불가)

• from의 패키지명 앞에 . 1개를 쓰는 경우 지역 디렉토리, 2개이상을 쓰는 경우 상위 디렉토리를 찾음.

이렇게 되어가고 있는데, 여기서도 구체적인 문법 모양 등의 사안에 대해서는 의견이 아직 분분하군요. 예를 들면 현재 같은 디렉토리에 있는 파일을 임포트할 때 import what하면 될 게, 이제 앞으로는 from . import what이 된다는.. 상위 디렉토리의 다른 패키지 모듈을 임포트 하는 경우에는 from ..subdir import what 이런식으로 일단은 될 모양이군요. (아직 결정은 안 됨)

이 이외의 의견으로는 이런 것도 있습니다. (다들 나름대로의 지지자들을 확보. )

• 상위 디렉토리에 올라갈 때 .대신 __parent__를 쓰고 현재 디렉토리에서 임포트할 때에는 __here__에서 임포트

• 상위 디렉토리에 올라갈 때 ../../ 식으로 슬래쉬를 넣자는 의견

• 그냥 상대경로 임포트를 놔둔 채로 표준 경로에서 임포트할 때 from stdlib import xxx로 하자는 의견

어떻게 될 지는 며칠 더 토론이 진행되어야 될 것 같습니다.

지난 5월이었던가요.. PyCon에서 Parrot(perl6에 사용될 JIT 지원 VM)팀의 Dan Sugalski가 귀도에게 내년에 패럿기반의 파이썬과 오리지널 CPython간의 벤치마크 시합을 해서 지는 쪽이 맥주를 사고 50달러 내기를 했던 것을 기억하실겁니다.

최근 Dan Sugalski가 이 작업을 위해서 본격적으로 벤치마크할 프로그램의 조건을 구체적으로 얘기를 꺼내기 시작했는데, 대충 파이썬 코어팀과 Dan간의 협의 사항은 이렇게 정해졌네요

• 순수 인터프리터 자체만 테스트하는 것을 목표로 함

• I/O 성능은 테스트하지 않음

• 정규표현식 성능은 테스트하지 않음

• eval과 expr은 테스트하지 않음

• 펜티엄 기반의 리눅스 박스에서 테스트함

• 파이썬 소스가 아닌, 바이트코드를 기반으로 하며 최소한 30초 이상 작동하는 코드로

• 바이트코드는 12월 내에 결정

• 확장 모듈은 사용하지 않고 빌트인 함수는 사용함

귀도는 Parrot이 엄청난 격차로 CPython을 이긴다면, CPython을 버리고 파이썬 기반을 패럿으로 옮겨버릴 수도 있다고 합니다. (과연.. )

며칠 전 Miguel의 블로그에 올라온 블로그가 크게 파장을 일으키고 있네요. Jython 개발자인 Jim Hugunin이 .NET 기반의 새로운 파이썬인 Iron Python을 만들어서 Microsoft 내부 메일링 리스트에 결과를 올렸는데, 예전의 Active State의 구현이나 Parrot계열의 Pirate의 실망스러운 결과와는 완전 상반되게 70%나 CPython보다 빠르다는 결과를 얻었다고 합니다. (원본 메일 (Miguel의 복사본))

특히나 function call, integer add쪽은 CPython에서 엄청난 오버헤드가 있는 것으로 유명했던 부분이라.. 역시나 IL asm으로 직접 번역하는 것으로 구현된 Iron Python보다 엄청나게 느린 것으로 결과가 나왔군요. 그리고 range의 경우에는 메모리 할당이 단편적으로 엄청나게 일어나기 때문에 CPython이 유리한 게 나왔고 eval(“2+2”)쪽은 CPython은 컴파일러가 순수 C로 구현되어있기 때문에, 흐흐..

하여간 .NET IL asm으로 직접(C# 안 거치고) 파이썬 코드를 번역하면 아무래도 CPython보다 더 빠르지 않을까 생각하던 초기 .NET 개발자들의 예상은 대충 맞았다는 것이 증명되고 있는 듯 합니다. 아직 Iron Python이 많이 구현되지 않은 반면 최적화를 수행하지 않았기 때문에, 앞으로 변동이 좀 있을 것 같기도 한데.. 하여간 무지 기대가 되네요. (MS에 팔아먹으면 대략 낭패 –; )

한편, Iron Python이 오픈소스가 아닌 MS나 다른 회사의 상용 제품으로 들어가는 것을 대비해서 최적화를 계획해야할 텐데, CPython도 이제 슬슬 표준 환경에서의 JIT 지원에 대해서 본격적으로 진지하게 고려해 봐야 할 것 같기도 합니다. (PyPython은 아직 까마득.. 으흐…)

http://sourceforge.net/project/memberlist.php?group_id=5470 (끝 쪽에..)

에헤헤.. 파이썬 커미터가 되었습니다. 앞으로 파이썬을 튼튼한 놈으로 키우겠습니다! (불끈!) 혹시 파이썬에 문제가 있는데 영어로 말하기 곤란하다 싶으시면 앞으로 문 앞에서 퍼키군을 찾아주세요 ~.~

멘터 Raymond Hettinger씨에게 이 자리를 빌어 많은 감사드립니다. (_ _) (한글은 모른다지만;;)

저는 앞으로 당분간은 PEP289 구현 팀에서 일할 예정인데.. 스물스물 문화를 익히고 나서는 cjkcodecs나 iconvcodec을 불쑥 집어넣을 기회를 노려 보겠습니다. –;;

포트 PR이 올라왔길래 한 번 해봤습니다. 흐흐 IPython은 예전에 나왔던 devel/py-repl 같이 파이썬 인터랙티브 인터프리터 프론트엔드인데 오토 컴플릿 같은 몇가지 유용한 기능을 추가로 지원하는 녀석입니다. py-repl이 국제화가 제대로 안 된 것에 비해 IPython은 그래도 국제화도 잘 되어있고, 다국어지원도 대비되어 있네요.

젤 독특한 것은 젠투 만큼이나 화려한 칼라인데.. -.- 프롬프트가 녹색이고 에러는 빨간색이고 아주 난리가 납니다. 흐흐 아아 그런데, 왜 정작 신택스 하이라이트는 안 되는거야!! ㅎㅎ ;; 정말 아쉽네요~

오리지널 파이썬의 것 보다 인덴트도 좀 더 똑똑하고, import c<tab>누르면

요렇게 임포트 할 수 있는 모듈 이름도 나오고.. 흐흐 py-repl보다 대체로는 만족스럽군요. 한글도 잘 되구요. 신택스 하이라이트만 되면 정말 좋을텐데~~ 크크

홈페이지는 http://ipython.scipy.org/ 이고, 포트에는 devel/ipython 으로 등록하려고 원 PR 저자에게 메일을 보냈습니다. 그 사람은 devel/py-ipython으로 만들었는데, 아무래도 모듈로 쓰이는 게 아니니까 그냥 py-를 안 붙이는 게 나은 것 같네요

Python 2.3.3이 2주일 내로 릴리즈될 예정이라고 합니다. (대략 크리스마스때 쯤..)

파이썬 역사상 가장 단기간에 .3까지 달아버린 이번 릴리즈에서는 이런 것들이 고쳐집니다:

• weakref 객체에서 segfault나는 버그 수정 (Blog0311/WeakrefObject)

• IntFutureWarning, apply 내장함수, coerce 내장함수 등 몇가지 2.4 이후 버전에 대해 유연한 업그레이드를 위한 경고 추가. (2.4부터는 apply 함수도 deprecate에 들어갑니다.)

• IDLE의 몇가지 버그 수정

• 파이썬이 죽을 때 gc가 콜렉션을 두번 해서 특수 환경에서 제대로 종료되지 않는 현상 해결

• object.contains (in 연산자)가 0/1이 아니라 True/False를 리턴하도록 수정

• 한글 음절을 노멀라이즈하는 도중에 죽는 문제 해결

• 내장 expat이 1.95.7로 업그레이드

• FreeBSD와 MacOS X에서 ncurses.h 경고 안 나오도록 수정

• distutils가 MSVC6에서 정상 동작하지 않는 버그 수정

이라고 합니다.