Month: August 2004

gmailfs

by

[WWW]libgmail 프로젝트에서 gmail을 위한 smtp, pop3, ftp 프락시를 만드는 것을 보고도 상당히 충격을 받았지만, 오늘 #perky의 Burnhard님께서 보여준 이 프로젝트를 보고서는 패닉에 빠져서 ~( _-_)~

[WWW]gmailfs는 리눅스와 SunOS에서 유저랜드측 프로세스에서 파일 시스템을 제공할 수 있게 하는 [WWW]FUSE를 기반으로 구현된 gmail 파일시스템입니다. 그리고 당연히 구현은 파이썬으로 되어있지요~ 흐흐; 이것 만든 사람은 이틀밖에 안 걸렸다니 참, 이거 libgmail의 위력이란~ :)

저자가 올린 [WWW]스크린샷을 보면 아이고 ;_; 흐흐 FUSE가 BSD를 지원 안 해서, 테스트 못 해보는게 참 한입니다. ㅠ.ㅠ 이제 FreeBSD책도 나오고 했으니 파일시스템 부분을 공부해서 프비 portalfs 부활운동을..

새로운 .NET 기반의 파이썬-비슷 언어 PyCs

by

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

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

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

곧 릴리스될 것들

by

작년 여름에도 그랬듯, 여름만 되면 FreeBSD와 Python 양쪽에서 활발한 릴리스 엔지니어링이 일어납니다. :) 아무래도 유럽사람들의 무진장 긴 (보통 1달) 휴가가 대체로 여름이라서 그런지도 모르겠군요~ 흐흐

하여간 이번에 FreeBSD는 5.3 베타에 이미 들어가서 곧 베타 2가 나올 예정이고, 빠르게 베타가 속속 나와서 결국 9월 3일에 포트 프리즈, 9월 17일에 RC 패키지 빌드, RELENG_5_3 브랜칭이 됩니다. 현재 남은 문제 중에서는 우선 어제 디폴트로 네트웍 드라이버에서 자이언트 락이 빠진 것과, 몇달 전에 들어왔던 preemptive mode를 켜는 경우에 아무데서나 막 행돼버리는 문제 같은 것이 아무래도 결정적이 될 듯하지만, 5.3이 전반적으로 수개월동안 꽤 안정적이었기 때문에, 별 문제 없이 10월에 5.3-RELEASE와 동시에 5.3-STABLE 브랜치가 나올 수 있을 듯 합니다. 포트에서는 xorg가 들어온 지 꽤 지나서, 처음 나왔던 문제들은 대체로 다 해결된 편이고, 5 브랜치가 워낙 오래된 브랜치라서 포트에서도 마찬가지로 큰 이슈는 없을 것 같습니다. 아쉽게도 Python 2.4 final이 적어도 10월은 되어야 나올 수 있을 예정이라, FreeBSD 5.3에 Python 2.4가 포함되지는 못할 것 같네요. (작년에 5.1에 2.3이 못 들어갔던 것과 같은 상황 Y.Y)

파이썬은 2.4의 세번째이자 마지막 알파 릴리스인 2.4a3이 9월 3일 릴리스 예정입니다. 2.4a3에서는 cjkcodecs와 관련되어서는 옛날 C 컴파일러들에서 돌아가는 문제가 수정되었고, 그 외에는 별 국제화 이슈에서 수정된 것은 없을 예정입니다. (u’한글’이 IDLE에서 되게 해야하는 문제가 있는데.. –; 이거 마비노기 때문에.. ;;) 그 외에는 데코레이터가 엄청난 반대에 부딪혔지만 아무래도 귀도는 그냥 밀어붙일 태세로 보이고, 전체적으로 버그 패치만 들어갔으며 부가적으로 지원된 특별한 기능은 없습니다. (FreeBSD 6 지원도 들어갔습니다. :) ) 2.4a3이후에는 베타 릴리스가 2개정도 나오고 RC 릴리스 1개 이후에 바로 파이널 릴리스가 나와서 최종적으로는 10월중에는 나오지 않을까 싶습니다. 그 다음엔 2.5, 2.6.. (다음엔 3.0? =3 -O-)

《클론 AND 클론》

by

[ISBN-8976829166] 당신의 머리카락에서 DNA를 추출해 클론을 만들었다면 그는 과연 당신인가, 아닌가?

이런 전산쟁이가 들으면 뻔한 얘기를 갖고 혼동하는 사람들을 클론 관련 토론을 보면 자주 보게 되는데, DNA는 클래스이고, “당신”은 인스턴스이기 때문에 당연히 다르고, 인스턴시에이션 된 후에도 꾸준히 어트리뷰트들이 바뀌겠다는 뭐 이런 생각을 하고 있었습니다. -O- 뭐 그래도 생명 복제를 어디까지 허용해야 하는가에 대한 건 아무래도 인스턴스를 복사하는 문제하고는 다른 것이라.. 생명 윤리에 대해서 머리 속에서 $@#&%*(@&#%(*로 생각하고 있었습니다. –; (접근하면 양 세는 것 보다 더 강력하게 잠오는 무한루프…)

그런데, 작년에 읽었던 프랜시스 후쿠오카의 《Human Future》를 읽고서는 아아 그래 뭔가 똑똑한 사람들이 이미 생각 개진을 많이 해놨구나 느끼고 있기는 했는데, 마침 오랜만에 책을 찾다가 뭔가 아주 사이비 종교 광고 책 처럼 생긴 《클론 AND 클론》을 발견했습니다. 표지와 제목은 영 미심쩍었지만, 그래도 저자 중에 굴드씨가 있었기에.. 믿고서는 :)

이 책은 99년에 나온 책인데, 돌리가 나온 직후에 여러 생명 윤리 관련 전문가들이 쓴 글들을 모아서 발간한 책입니다. 굴드 같은 이 분야의 전문가들의 냉철한 글외에도 SF 소설가들의 복제가 일어난 후의 세상을 그린 소설, 철학자들의 여러 철학론에 비춘 해석, 종교계 윤리학자들의 종교적인 관점에서의 이성적인 해석 등 여러가지 유익한 글들이 엮여있습니다.

처음에는 소설 여러개가 엮여 있는데.. 이 책을 번역한 이한음씨가 아무래도 과학서만 번역하던 분이라 그런지 무미건조에 하나도 재미가 없는 1장을 채 읽기가 힘든 이 문체란.. ;; 꿋꿋이 참고 그래도 몇페이지 읽다가 결국은 소설을 넘겼습니다. -0- 그 다음부터는 이제 굴드, 도킨스, 조지 존슨 등의 유명한 과학자들의 글이 나옵니다. 굴드씨의 글은 아주 짧은데 일란성 쌍둥이는 이미 과학적으로 가능한 클론보다도 더 완벽한 클론인데 왜 사람들은 클론에 대해서 그렇게 부정적인가에 대해 분석을 하고 있는데, 그 주된 문제점으로써 일란성 쌍둥이는 동시에 태어나기 때문에, 서로의 존재가 다른 사람들에 대해 정체성의 문제가 될 정도로 심각한 일은 없는 편이지만, 클론은 시간적 차이가 있기 때문에, 뒤에 태어난 클론이 앞에 태어난 원본의 삶에 일어나는 여러 일에 대해 충격을 받거나 운명으로 받아 들이고 비관적으로 살 경우 같은 점을 들고 있습니다. 아아 흐흐 이건 전혀 생각을 못 했던 것인데 이런 문제가 있군요. -O-;

도킨스씨는 역시 한쪽 끝 끌개 지역에 분포하는 사람이라, 글도 아주 과격하게 전혀 반대할 이유가 없다하고서 여러가지 논거를 내세우고 있습니다. 뭐 자세한 것은 워낙 긴 논리적 전개가 필요해서 직접 읽어 보셔야 겠지만, 논리적이지 않은 반박을 하는 일부 과격한 종교계 사람들의 전형적인 예에 대한 설명을 듣고 나니, 그 사람들 패턴이 이해가 됩니다.;;

“”” 이 토론자들 가운데 가장 유명한 사람은 최근에 주님의 전당에 뽑힌 사람이었는데, 그는 텔레비전 스튜디오에서 여성들과 악수하는 것을 거부함으로써 토론을 신속하게 시작되도록 하는데 기여했다. 그의 악수 거부가 여성들이 생리 중이거나 불결할지 모른다는 두려움 때문이라는 것은 명백했다. 여성들은 그 성직자에게 종교적 선입관에 항상 수반되기 마련인 ‘존경’을 표하면서, 나라면 도저히 할 수 없을 정도로 매우 우아하게 그 모욕을 받아들였다. 패널 토론이 시작되고 좌장인 여성이 이 턱수염 난 성직자에게 정중히 경의를 표하면서, 복제가 피해를 끼칠 것인지 말씀해달라고 부탁하자 그는 원자폭탄은 해롭다고 대답했다. 그렇다. 거기에는 정말 반대 의견이 있을 여지가 없다. 그러나 복제를 논의하기로 예정되어 있던 토론은 어디로 갔단 말인가? “””

역시 도킨스씨는 끝까지 아주 다혈질적으로 맹렬히 공격하고 있는데, 음 그래 그래~ 하면서 그런대로 수긍이 흐흐; 물론 도킨스씨 글 같은 것만 있으면, 뭔가 균형이 안 맞았겠지만, 미국의 국가 생명 윤리 자문 위원회나 윤리학 교수, 법윤리학 권위자들의 글들이 후쿠오카의 글에서처럼 “아 이런 똑똑한 사람들! 이런 것도 생각했군!”하는 탁 치게 만드는 논리들이 전개가 돼서 “그래 나는 세상 걱정 안 해도 되겠구나~”하는 결론만;;;; 얻게 되었습니다. 흐흐

생명윤리에 대한 토론은 아무래도 그동안 여러 군데서의 경험을 보면 그냥 쉽게 감정적인 자기 논리 세계를 기반으로 한 단방향적인 주장이 연속되다가 그냥 감정싸움으로 끝나는 경우가 많은데, 이런 책에서 체계적인 논리적 주장들로 종교/윤리적 관점의 반론이 전개되는 것을 보니 굳이 이런 얘기는 아무데서나 할 필요가 없겠다는 생각이 듭니다. ^-^;; (결국은 이런 산만한 결론으로 치닫는다.. –;)

그래요, “과학과 논리학은 무엇이 옳고 그른지 말해줄 수 없는” 것이지요. (리처드 도킨스)

《The Design and Implementation of FreeBSD Operating System》 도착!

by

0408-dnifreebsd.jpg

드디어 고대하던 그 책 D&I of FreeBSD가 도착했습니다! 미리 아마존에 예약을 했는데도 꽤 늦게 도착을 했네요.. 영업일 3~5일이라더니 실제로는 8일째에 도착을.. ㅠ.ㅠ

아아 처음 딱 받은 소감은?

오우. 뭔가 패키징이 감동입니다. 역시 국내 배송과 해외 배송은 좀 다른 걸까요.. 비닐 공기 팩으로 꽉 채우고 책 자체도 안 움직이게 골판지를 대서 비닐에 싸놨군요. 전에 아마존 재팬에서 DVD 살 적에는 제법 허술하게 와서 실망 했었는데.. 흐흐. 역시 책이라 그런지 10만원 이하라 그런지 관세는 따로 없군요. 표지가 검은색에 오렌지라 4.4BSD 책 보다 뭔가 뽀대가 납니다. -O-

전체적인 구성은?

책 안의 디자인은 4.4BSD 책과 거의 똑같습니다. groff류의 툴들을 쓴 게 그대로 그냥 개정된 것이라 그런지.. 여전히 글자는 좀 지나치게 빡빡한 면이 있고 한데.. 뭐 빡빡한 대신 내용에 비해 얇아져서 그런대로 들고 다니면서 보기도 좋은 것 같은 것으로 위안을.. 흐흐; 역시 4.4BSD 책의 후속편 답게, 많은 부분에서 4.4BSD책을 기반으로 쓴 흔적이 남아 있습니다. 그렇지만 아무래도 세월이 많이 지나고 내부 구조가 바뀌다보니 뒷부분으로 갈 수록 새로 쓴 부분이 많아져서, 전체적으로 보면 FreeBSD 5.2 커널의 반 정도는 커버하고 있다고 볼 수 있겠네요. 이번에 실질적으로 내용을 쓴 Neville-Neil씨가 원래 글을 잘 쓰는지, 딱딱하고 지루하기 짝이 없는 4.4BSD 책의 문체에서 많이 벗어나서 쉽고 눈에 잘 들어오는 문체로 대폭 개선된 듯 해서 아주 읽기가 편합니다.

FreeBSD 고유의 업데이트들은 잘 반영이 되었는가?

우선, 최근에 등장한 FreeBSD 고유의 디자인들인 CAM, GEOM, ULE scheduler에 대해서는 어느정도 잘 다루고 있고 특히 softupdate와 UFS2에 대한 내용은 최근 업데이트까지 모두 아주 자세히 설명하고 있습니다. 그런데, KSE, netgraph, kld, 802.11, ipfw, acpi 같은 부분은 제법 관심이 있을 만한 주제인데도 빠져 있어서 조금 아쉽군요.

책의 난이도 및 구성의 품질은?

책의 난이도는 4.4BSD 책보다는 설명이 쉽게 되어 있어서 이제 어느정도 학부 교재로도 쓸 만큼 되었습니다. (앞쪽 책 소개란에 학부 교재로 쓰면 어떤 숙제가 좋은 가 얘기도..;;) 그런데 아무래도 OS의 기초부터 뭔가 다루는 책은 아니니까.. 그냥 부교재 정도로.. -o-; 비슷한 소재의 책 중에서 단연 최고의 인기인 《Solaris Internals》에 비해서는 FreeBSD 고유의 독창적인 디자인들과 FreeBSD를 소재로 쓰여져 있다는 장점은 있지만, 여전히 Solaris Internals가 그림이 훨씬 알기 쉽게 그려져 있고 설명이 친절해서, FreeBSD에 애착이 있는 독자가 아니라면 그냥 《Solaris Internals》가 읽기 좋을 것 같다는 생각이 듭니다. 책 중 8페이지가 연속으로 그림, 소스, 표 전혀 없이 본문만 연속될 때는 마치 오픈룩 블로그처럼 삭막하다는 압박감이 느껴지는군요. -O-

예~ 전체적으로 지난 버전에 비해 개선되고 재미있어졌지만 약간 아쉬운 점도 있습니다. 그래도 BSD 사용자라면 꼭 한 권쯤은 사 둬야 할 책인 듯 하네요. 버스에서 슬쩍슬쩍 읽어보는데도, 참 “아 내가 이렇게 생긴 OS를 쓰고 있었군~!”하는 느낌이 새록새록.. (4.4BSD는 좀 읽다가 포기 –;;)

FreeBSD 5.3 Beta1 릴리스

by

FreeBSD 5의 첫번째 안정버전 릴리스인 [WWW]5.3의 Beta1이 나왔습니다. 아직 5.3에서도 완전하지 않은 기능들이 많이 있지만, 그래도 계속 CURRENT로 남겨둬 봐야 계속 불안정한 것들이 들어올 것이니 언젠가는 적당히 STABLE로.. 흐흐.. 아직 SMP지원에 문제가 있기 때문에 SMP 사용자는 BETA2까지 기다리 라는군요.

이제 openlook도 5.3-BETA1로 올려야겠군요~ :) 참, 그리고 Python 2.4a2는 9월 2일에 나올 예정입니다.

HP 테스트 드라이브

by

최근에 CJKCodecs 1.1과 Python 2.4a2가 릴리스된 후에 구형 C 컴파일러를 사용하는 분들께 버그 레포트를 빗발처럼 받았습니다. -o-; 이번에 완전히 새로 구현한 _codecs_iso2022.c 에서 구조체 끝에 크기가 지정되지 않은 어레이인 C99 문법을 쓰는 바람에 gcc3이나 VC++에서는 잘 됐지만, gcc2나 HP-UX, IRIX, Tru64 같은데서 에러가 났던 것입니다. 근데 gcc2에서는 어레이 크기를 0으로 써버리는 수법으로 우선 에러를 넘길 수 있긴한데 다른데서는 따로 할 방법이 없어서 우선은 풀어쓰는 방법으로 패치를 올리고 버그를 보고한 사람들에게 테스트를 해 달라고 했는데, 이게 계속 왔다갔다 해야하다보니 불편해서, 시간이 꽤 오래 걸렸군요 흐흐

그래서 뭔가 좋은 방법이 없을까 하다가 생각난게 [Python]PythonTesters 페이지에 있는 HP Test Drive에 대한 내용이었습니다. 아무나 계정을 주긴 한다는데.. 정말로 줄까~ SF 처럼 상상을 초월하도록 느리지는 않을까 하는 걱정이 있긴 했지만.. 그래도 한번 해 보자 하는 다짐을 하고~ [WWW]TestDrive에 접속해 봤습니다. 아아 가입하는 페이지가 무척 간단한데, 가입을 작성하고 나면 바로 메일로 비밀번호와 접속할 수 있는 머신들의 IP주소가 날아옵니다. ssh가 아니라 telnet으로 열어주는데, 들어가는 포트와 나가는 포트가 ftp와 telnet을 제외하고는 완전히 막혀있기 때문에 웹에서 뭘 받는다거나 scp로 올린다거나 그런게 전혀 불가능합니다. 오로지 소스를 올릴 때는 ftp로 올려야하고 telnet으로 작업을 해야하는 뭐 적당히 답답한 환경이군요 흐흐 속도도 그럭저럭 빠르고! 제공되는 머신은 한 30개정도 되는데 FreeBSD 클러스터 처럼 NIS와 NFS로 묶여있어서 아무데나 올려도 같은 홈디렉토리처럼 쓸 수 있어서 아주 편합니다. :)

지원되는 OS들은 HP-UX, Tru64, OpenVMS, FreeBSD, NetBSD, Debian GNU/Linux, Mandrake Linux, RedHat ES/AS, SuSE Linux 등이 있고, 아키텍처도 OS마다 다양해서 Alpha, Opteron, IA64, IA32, EV5/6/7 등등 다양하군요. 그리고 기본으로 다 C 컴파일러가 HP에서 파는 것과 GCC가 깔려있어서 그런대로 테스트 환경으로 편한 편입니다~ 그리고, 오라클 테스트도 할 수 있게 돼 있는데.. 뭐 오라클은 할 줄 몰라서;; -ㅇ-

흐흐. Tru64 C Compiler는 특히 에러 내용이 무척 친절해서 포터빌러티 테스트를 할 때 정말 좋은 것 같네용.. 멀티 플랫폼 개발하는 분들께는 꼭 추천입니다. :)

Rivest씨, 알고 보니 파이썬 사용자!

by

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

PEP3000 등장

by

얼마전에 Python 3000에 대한 대략적인 것을 이제 슬슬 정해 보자고 토론 되었던 대로, 오늘 [WWW]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배는 더 많이 충격적인 내용이 들어가야 할 것 같은데~ 모두 좋은 아이디어를 생각해 봅시다 크흐흐;

파이썬 유니코드/스트링 이슈

by

요즘 파이썬계에서는 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 아주 기대가 되는군요. 냉큼 바뀌면 좋겠습니다. ㅋㅋㅋ (그러나.. 그 기존에 문자열을 바이트 시퀀스로 쓰는 대부분의 코드들은 어찌 포팅할지 -ㅇ-)