AMK가 말하는 파이썬의 미래

by

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

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

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

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

파이썬 프로그래머는 진짜로 자바 프로그래머보다 똑똑한가?

by

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

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

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

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

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

Subversion 이제는 안 꺠지는가!

by

추석동안에 소리 소문없이 슬쩍 subversion 1.1이 stable release로 나왔네요. 그동안 회사에서 “으악~~ DB가 깨졌어~~” 소리가 하루 종일 열댓번씩은 났던 것을 생각해 보면, subversion 1.1에서 나왔다는 fsfs는 정말 기대가 됐습니다.

그래서 냉큼 subversion 1.1을 깔고 레포지트리를 덤프 뜬 다음에 fsfs로 바꿔버렸습니다. 리비전이 1200정도 되는데, 워낙 서버가 느려서 한 5분 정도 걸리는군요.. 그런데 게다가 woody라서 그나마 나오는 패키지도 다 옛날 버전이고.. 흐흐흐; 그냥 간단하게 ./configure 했더니 버클리DB 없이 컴파일했다는 워닝이! 캬! 그래 이게 바라던 거였어! (subversion으로 인해 버클리DB에 쌓인 감정이 많다..;)

원래는 레포지트리/db/db.00* 와 레포지트리/db/log.00* 파일들이 흉칙하게 남아있었는데 이제는 fsfs로 하면 레포지트리/db/{revs,revprops,transactions} 밑에 숫자 1~5자리 정도로된 파일이 수백개씩 들어갑니다. 다행히 리비전 1개에 파일이 1개… (리비전 1개의 파일당 1개였으면 –;) FreeBSD 레포지트리처럼 리비전이 80000쯤 되면 디렉토리당 파일이 80000개 -ㅇ- 뭔가 대책이 필요합니다 =.=; 그런데, 처음 fsfs 말을 들었을 때 기대했던 CVS처럼 사람 눈에게도 친절한 포맷은 아닙니다. 그렇다고 완전 못알아 볼 포맷도 아니긴 하지만.. 하여간 RCS는 아니군요 (별 기대를 -ㅇ-)

속도는 특별히 버클리DB로 쓸 때보다 차이가 있는 것 같지는 않습니다. blame이 좀 느리다는 얘기를 들었는데 체감 속도로는 별 차이가 안 나는군요.. (어차피 느려서;;)

대충 아무렇게나 막 while루프로 svn에 접속시켜봤는데, 버클리DB를 쓰던 시절 같으면 금세 깨져버렸을텐데 아직 멀쩡한 걸로 봐서, 그런대로 안 깨진다는 것은 사실인 듯 합니다. 이제 마음 졸이며 DB 복구하는 시절은 갔군요. 으흐히;;

Twisted Web은 그냥 장난감이 아니다?

by

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

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

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

《나무》

by

[ISBN-893290507X] 어댑터가 없어서 충전도 안 된 노트북 부여잡고 뒹굴뒹굴 대던 지루한 추석 연휴를 마치고 서울로 돌아오는 길에 노트북도 여전히 못 만지고 해서, 오랜만에 기차 안에서 우아하게(ㅋㅋㅋ) 책이나 읽어볼까 하고 동생 책을 하나 빼 왔습니다. 딱히 눈에 띄는 것도 없고 해서 동생이 골라 주는 것을 아무거나 덥석 집어 왔는데, 이름은 많이 들어봤지만 평소에 픽션은 거의 안 읽는 터라 실제 작품은 한 번도 못 읽어본 베르나르 베르베르의 《나무》였습니다. 그동안은 베르나르 베르베르 작품은 왠지 이름에서 지지리 궁상 얘기 뭐 그런 것 같은 분위기가 물씬 나서.. (아무래도 베르테르의 영향이리라 –;) 거부감이 있었지만, 삽화가 재미있어 보여서 마음이 내켰습니다. 으히히 :)

나온지 꽤 오래된 책이고 이미 베스트셀러에 한참 전에 있었던 책이라 많이들 읽어 보셨겠지만, 아아.. 이 충격이란! 첫 작품인 “내겐 너무 좋은 세상”부터가 그래! 소설이라면 이렇게 재미있는 상상을 할 수도 있지! 하고 탁 치며 상상의 나래를 펼치면서 순식간에 빨려 들어가 버렸습니다. (재미없는 영화를 봐도 감정이입을 잘 하는 성격..) 흐흐 바로 그.. 가전제품들이 다 감성화가 되어서 조용한 옛날 가전제품들이 더 그립다는.. 사실 저도 전에 한번 꿈에서 나온 적은 있는 얘기이긴 하지만 흐흐..

그 이후에도 투명 피부이야기, 타임머신 이야기, 고령 사회 이야기, 인간이 아닌 종이 인간을 애완 동물로 사육하는 방법을 적은 이야기 등등 꿈 속에서 한번씩은 비슷한 상상을 해 봤음직한 얘기들을 정말 고루고루 재미있게 그려내고 있는데, 정말 얘기에 흠뻑 빠져서 얘기 하나 읽고서는 한 20분은 그 생각에 이리 저리 엉뚱한 생각을 덧붙여보고.. 치매 예방에 정말 좋겠습니다 =.=;;

흐흐.. 혹시나 아직 안 읽어보신 분 중에 공상과학 꿈을 주로 꾸는 분들은 꼭 읽어 볼 만 합니다. :)

재미있었던 묘사를 하나 인용.. 이히히

“”” 냄새는 날이 갈수록 더욱 독해졌다. 그러자 어떤 유기물 덩어리가 운석 내부에서 부패하고 있기 때문일지도 모른다는 가정이 제기되었다. 냄새가 오죽 역겨웠으면 파리들조차 멀리 날아가 버리는 판국이었다.

그 악취에 태연할 수 있는 자는 아무도 없었다. 코의 내벽이 따끔거리고 목구멍에 염증이 생기는가 하면 혀까지 뻣뻣해지는 느낌이 들 정도였다. 천식 환자는 숨이 차서 헐떡거렸고, 코가 막혀서 입으로 숨을 쉬던 감기 환자조차 입 벌리기를 두려워하였으며, 개들은 죽어라 하고 울부짖었다. — 68페이지, “냄새” “””

“”” 하지만 기계가 사람처럼 구는 것도 어느 정도지. 이건 해도 정말 너무했다. 가장 하찮은 도구들조차 제가 맡은 일을 주도적으로 하겠다고 기를 쓰는 상황이 되었으니 말이다. 셔츠는 제 스스로 단추를 채웠고, 넥타이는 마치 뱀처럼 제 스스로 사람의 목 주위에 감겼다. 텔레비전과 하이파이 오디오 세트는 서로 자기가 먼저 집주인을 즐겁게 해 주겠다고 다투었다.

사정이 이쯤 되고 보니, 뤽은 때때로 소박하고 말 없는 옛날 물건들이 그리웠다. 온-오프 스위치가 달려 있어서 사람 손이 가야만 움직이는 가전제품들, 금속으로 된 작은 종을 두드려서 소리를 내는 태엽 자명종, 삐걱거리는 문, 자력으로 움직일 수 없고 그래서 위험하지도 않은 실내화, 요컨데 생명의 흉내를 내지 않는 물건들이 말이다. 하지만 그런것들은 이제 골동품 가게나 가야 찾아볼 수 있다. — 15페이지, “내겐 너무 좋은 세상” “””

“””

.sex는 위험하다.

by

으흐흐. 정말 오랜만입니다. 추석에 집에 갔는데 노트북 어댑터를 놔두고 가는 바람에 전원 안 들어오는 노트북을 부여잡고서는 –;; ;_;

지난 주에는 퇴근길에 읽을 만한 문서를 보다가 rfc:3675 를 인쇄했습니다. rfc3675 .sex Considered Dangerous는 98년부터 꾸준히 있어왔던 .sex 도메인에 대한 역사적인 문제점들을 다루고 있습니다. .sex TLD의 기본 목적은 애들한테 유해하다고 판단되는 야싸이트들을 .sex로 분리해서 쉽게 막을 수 있도록 하자는 것인데, rfc3675에 따르면 98년부터 미국 의회나 여러 사회단체에서 꾸준히 ICANN에 압력을 넣고 있었다고 합니다. 그렇지만, ICANN에서 꿋꿋히 저항해서 결국은 아직도 안 들어가고 있다고 하는데, rfc3675에서는 그 이유에 대해서 이모저모 아주 요약된 설명을 하고 있습니다.

기본적으로 .sex를 주장하는 목적은 .sex에 18세 미만이 접근할 수 없는 사이트들을 분리하고, .kids에 애들한테 안전한 사이트를 넣고, 마지막으로 위험한 사이트들을 IP에서 특정 영역으로 분리해서, 애들한테 라우팅을 안 해 주는 것 까지 포함하고 있습니다.

rfc3675의 저자는 여러가지 이유에서 이런 것을 반대하고 있는데 대충 요약하면 이렇습니다.

  • 나라마다 미성년자 기준이 다르다. 대부분은 18세를 택하고 있지만, 스칸디나비아 반도에서는 17세이며, 20세인 곳도 있다.

  • 나라마다 미성년자에게 허용하는 범위가 다르다. 미국같은 경우에는 성인물에 대해서 아주 보수적인 편이지만 러시아나 북유럽같은 경우에는 아주 관대하다.

  • 성인물 뿐만 아니라 수백가지의 아동 격리 대상 컨텐트가 있다. 현재 국제적으로 분류된 [WWW]PICS 만 보더라도 300개 정도는 충분히 나올 수 있고 그 300개의 대상에 대해서 일일이 TLD를 만들거나 2진법에 대해서 분류하다가는 도저히 칠 수 없을 정도 길이의 도메인이 나올 것이다.

  • 현재 사용하고 있는 상당수의 프로토콜은 도메인에 따른 컨트롤이 불가능하다. 대표적으로 HTTP같은 경우도 IP로 링크하는 경우가 있을 수 있으며, IRC는 사실상 도메인 기반의 접근 제어가 불가능하다. 또한 메일의 경우에는 각각의 라우팅을 모두 고려하면 사실상 TLD에 따른 제어는 무용지물이다.

  • IPv4의 경우 존에 따른 연령별 분리가 사실상 전혀 불가능하다.

  • IPv6의 경우 128bit 존으로 기술적으로 .sex 하나에 대해서만은 가능하지만, 컨텐트 제어에 사용될 300여가지의 분류(폭력성, 변태성, 정신이상성, 반사회, 마약, 정치적 사상, 범죄 합리화, 무법행위 등등) 를 다 도입할 경우에 128비트로도 도저히 수용을 못 할 것이다.

흐흐흐. 저도 그냥 .sex 있으면 구분하기 편하겠다 하고 생각하고 있었는데, 이런 문제를 꼬치꼬치 보고 나니 정신이 아찔하군용~ 그런데, 딱히 대안이 없는 것이 약간 서운하긴 하지만.. 며칠동안 출퇴근길에 고민을 해 봐도 정말로 대안이 적당한게 없군요.. 제 생각에는 미국같은 보수적인 동네에서 가장 많이 신경 쓰는 성적인 것들에 대해서는 점차 성인물의 기준을 낮춰서 그냥 적당히 사춘기만 넘기면 다 볼 수 있게 해버리면 어떨까 합니다. -ㅇ-;; (그 전에는 관심이 없을테니..)

소스포지 개발자에게 iPod 170개를 드립니다!

by

오늘 소스포지에서 메일이 하나 왔는데 마치 개인메일처럼 와서 자세히 읽어 봤습니다. 내용을 보니 소스포지 관리자가 C 카테고리에 들어있는 프로젝트 어드민 전부에게 1:1로 보낸 내용이군요 –;;

내용은 IBM이 총 170개의 iPod mini를 소스포지 개발자들에게 준다는 내용입니다. ([WWW]행사 URL) 단, 아무나 주는 것은 아니고 다음 조건을 만족해야 하는군요. 흐흐

  • 결정을 하는 12월 초에 LinuxPPC 플랫폼을 지원하는 프로젝트일 것.

  • 현재 이미 LinuxPPC에 포팅된 프로젝트면 불가능.

  • 자바 또는 스크립트(php,python,perl,ruby…) 기반이면 안 됨.

  • 서버 기반 프로그램일 것. (인스턴트 메신저 같은 데스크탑 기반이면 안 됨)

  • 소스포지 약관에 동의할 것

  • 9월 24일 자정(미국 동부시간)까지 신청한 프로젝트에 한해 12월 초에 결정을 하게 됨.

저는 이 조건들을 만족하는 프로젝트가 소스포지에 1개 ([SourceForge]openseed) 밖에 없어서 아직 고민 중입니다. –; openseed는 버린지 3년 넘은 프로젝트인데 -ㅇ- 으흐흐 조건을 만족하는 분들은 한 번씩 해보세요 +_+

ZFS

by

Sun Microsystems에서는 최근에 솔라리스 10에 탑재될 새로운 파일 시스템인 [WWW]ZFS에 대한 대폭적인 정보를 메일링리스트와 웹 페이지를 통해서 제공하기 시작했습니다. ZFS의 Z는 zsh의 z처럼 마지막이라는 뜻이라는군요. 지금까지 아주 다양한 파일시스템들이 왔다갔다 했던 다른 운영체제들과는 달리 계속 FFS/UFS계열의 파일시스템을 사용해 왔었는데, 이번에 ZFS로 옮겨감으로써 한꺼번에 다른 파일시스템들의 기능/성능/확장성 모두를 뛰어넘으려고 하는 모양입니다.

우선 가장 독특한 특징은 엔디안 중립적인 구조를 많은 부분에서 채용해서, 스팍에서 쓰던 디스크를 바로 x86에서 쓸 수 있다고는 하는데, 엔디안 마크를 일일이 쓰는 것인지, 한 엔디안으로 통일한 것인지는 잘 모르겠군요. 그리고, 현재 대부분의 파일시스템들이 32비트 또는 64비트 기반인 반면에, ZFS에서는 128비트 주소를 사용하기 때문에, 논리적으로 현재의 시스템들보다 160억배 크기까지 확장될 수 있다고 합니다. 128비트 기반을 하는 것에 대해서 freebsd-hackers 메일링리스트에서 논평이 몇 있었는데 재미있는 평으로 “Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn’t fill a 128-bit storage pool without boiling the oceans.” (128비트 파일 시스템은 지구 기반의 스토리지의 퀀텀 한계를 초과할 것이다. 바다를 다 끓이기 전까지는 128비트 스토리지를 다 채우지 못할 것이다) 라고 엄살을 떠는 사람도 있는데, 사실은 지금까지 생산된 어떤 트랜지스터 속의 원자수도 2128개를 넘고, 웬만한 박테리아도 그정도 원자 수는 넘는다고 다른 사람이 꼬집어 줬습니다. 흐흐흐. (아니 그럼 원자 단위로 저장을 하자는 말이냐! =3) 그런데 128비트 스토리지를 찾아댕기려면 어떻게 해야하느냐, 배드섹터 체크하다가 10년 가는 것 아닌가 뭐 이런 잡다한 얘기가 나오긴 했는데, 대체로 언젠가는 128비트가 쓸모가 있을 날도 올 지도 모른다… 난 결론으로 간 듯 합니다. 흐흐;

ZFS의 또 다른 멋진 기능으로 RAID를 무색케하는 스토리지 풀 기반의 볼륨 관리 시스템(GEOM이 아예 파일 시스템 레이어로 내려간 듯한 느낌이..)과 fsck, newfs 등의 파일 시스템 관리가 전혀 필요 없이 스스로 관리한다는 점. (구체적으로 어떤지는..) 데이터 무결성을 위해 완전히 데이터가 커밋(sync)되기 전까지는 절대로 이전의 정보를 덮어 쓰지 않는 것이나, 심지어 파일시스템 주제에 롤백까지 지원한다는군요. 아무래도 저널링 파일 시스템들과 유사한 혜택들을 저널링없이도 충분히 괜찮게 구현을 하려는 것이 목적인 듯 합니다. 그동안 유독 엄청나게 느린 파일시스템으로 사용자들을 괴롭혀 온 Solaris가 10에 이르러 이제 극락으로 변신할 수 있을지 릴리스가 기대가 됩니다.

DJ Max

by

으흐흐. 요즘 집 컴퓨터가 게임방 컴퓨터화를 거듭하고 있습니다. 온갖 게임에 메신저에 -ㅇ-; 아이고 ;_;

어제는 [WWW]토끼군의 소개로 [WWW]DJ Max라는 게임을 했습니다. 예전에 날리던 BM98류의 온라인 게임인데 전에 어디선가 온라인화를 한번 시도했다가 말아먹고 그 뒤로는 온라인 리듬비트게임이 별로 안 나오다가 이제 새로 나왔군요. BM98을 잘 하는 건 아니지만 그래도 아주 좋아하며 했었기 때문에 이거 참 정말 재미있습니다. +_+

0409-djmax1.jpg

흐흐 예전에 리듬비트류 게임 만드는 아르바이트를 했을 때 곡들이 참 좋았는데 게임도 못 뜨고 사장돼서 참 마음이 슬펐는데, 이 게임들 곡들도 역시 비트가 단순한 것이 아주 마음에 듭니다. (에.. -O-) 특히 “아침형인간”과 “Funky Chups”는 아주 발랄한 것이 좋습니다. 이히히. 옛날 기억들이 새록새록 나는군요. 멀티플레이를 하는 경우에는 자기 화면 옆에 쪼그맣게 다른 사람 화면들도 나오는데, 어제 같이 게임을 했던 토끼군과 토끼군의 동생은 어찌나 잘 하는지 난이도 7짜리를 MAX로 .. 역시 게임은 선천적인 뭔가가 있어야.. ;_;

0409-djmax2.jpg

리듬비트아케이드 팬들이라면 해보면 꼭 좋을 듯 합니다. ^^;

Internationalized Resource Identifiers

by

그동안 “URL을 항상 UTF-8로 보냄을 끄시오.” 이런 류의 불친절하고 무식하기 짝이 없는 문구를 여러 사이트에서 보아 왔습니다. 이제 더 이상 주소창에 한글을 쓰기 위해서, 최종 사용자가 인코딩을 신경써야 할 필요가 없습니다!

원래 URI에서는 US-ASCII외의 문자는 사용이 전혀 금지되어있습니다. 따라서, URI에는 한글을 못 쓰는 것이 당연한데, 이를 퍼센트 이스케이프를 사용해서 EUC-KR이나 UTF-8로 인코딩해서 보내 왔습니다. MSIE의 디폴트 옵션과, 모질라 계열 브라우저에서는 UTF-8을, Safari와 맥용 MSIE, 국내의 많은 사이트에서는 EUC-KR로 인코딩한 것을 쓰고 있어서, 사실 여러 인코딩의 난무에 제대로 보이게 해 주기가 곤란했고, 가장 심각한 경우가 블로그 trackback의 초기 스펙에서 GET으로 보내는 바람에 자기 사이트와 상대 사이트의 인코딩이 같아야만 트랙백이 깨지지 않고 보내는 문제까지도 발생했었습니다.

곧 RFC에 등록될 [WWW]draft-duerst-iri-09에서는 이 문제를 해결하기 위해서, IRI를 소개했습니다. 이 작업은 W3C의 주도로 이뤄지고 있는데, Microsoft 직원도 공동 저자로 표기되어있는 걸로 봐서 MSIE에서도 곧 지원하지 않을까 합니다. (물론 CSSv3같이 자기가 만들고 자기가 지원 안하는 경우가 있을지도 모르겠지만 –;)

IRI에서는 그냥 인코딩을 UTF-8로 쓰는 것이나 사실 비슷하긴 한데, 오른쪽에서 왼쪽으로 쓰는 언어를 위한 BiDi 지원에 대한 고려를 좀 추가하였고, 정규화를 NKFC또는 NFC로 명시해서 웹서버를 좀 더 편하게 해 주고 있습니다. 단, IRI는 URI를 기존에 쓰던 위치에서는 그대로 못 쓴다고 명시를 하고 있는데요. 즉, 아직 “URI”를 쓴다고 표시하고 있는 표준에 대해서는 그 위치에 IRI를 바로 쓰는 것이 아니라 IRI를 URI로 변환한 다음에 쓰도록 하고 있습니다. 하지만, IRI를 URI로 변환하면 사실상 정규화와 BiDi를 제외하고는 거의 그냥 UTF-8에 퍼센트 인코딩만 추가한 것이나 비슷한데, “항상 UTF-8로 URL을 보냄을 끄시오.”하는 우리나라 웹 실정과 맞을 지는 의문입니다. –;;

파이썬의 urllib{,2}에서도 draft-duerst-iri-09가 RFC에 등록되자 마자 바로 지원을 할 예정입니다.