파이썬 마을 입추 기념 번개합니다

입추 기념(;;)으로 파이썬 마을 번개를 오랜만에 합니다. 사실 그동안 제가 대전에 있어서 별로 모임을 못 가서, 휴가 틈을 타서 한번 서울 갈 핑계를 만들어보고자.. ^_^;;

  • 일시: 2007년 8월 10일(금요일) 오후 8시~
  • 장소: 포스코사거리 JS타워 야후코리아 10층 서니베일 회의실
  • 내용: 오후 8시~9시30분 – 파이썬 3000과 관련된 잡담과 토론. 그 이후 주변 어딘가에서 뒷이야기
  • 참가비: 뒷풀이 비용에서 1/n 더치, 잡담은 참가비 없음 (야후코리아에서 간단한 다과 제공)

참가신청은 파이썬마을 자유게시판에서 선착순 20명 받겠습니다.
장소가 한정되어 있어서 딱 자를 계획이니 꼭 참가하실 수 있는
분들만 신청해 주세요~ 🙂

파이썬 마을 번개 장소를 구합니다

글도 별로 없는 블로그에 광고를 해서 무척 죄송합니다. -ㅇ-;
그래도 곧 번개 소식이 약간 가미되어 있으니 정보가 되지 않을까 하고 예쁘게 봐 주세요. 🙂

이번 주에 여름 기념으로 오랜만에 파이썬 마을 번개를 한번 할까합니다.
그냥 번개만 하면 썰렁하니까 Python 3000에 대한 얘기를 조금 하다가
밥먹고 뒷이야기를 하는 자리를 만들려고하는데, 우선 조용하게 모여서
얘기할 곳이 필요해서, 토즈 같은 모임 전용 공간을 쓸 수도 있겠지만
참가비를 안 받고도 할 수 있으려면 혹시 파이썬 마을 회원 분들 중에서
회사나 학교에서 공간을 빌릴 수 있는 분이 있으시다면 그 편이 편할 것 같아서
우선 공개적으로 한번 구해 봅니다.

공간은 20명 내외가 원형또는 사각형으로 모여서 얘기할 수 있는 곳이면
좋구요. 프로젝터를 사용할 수 있어야 합니다. 물론 많은 분들이 쉽게
모일 수 있어야 하기 때문에 되도록 서울에서 교통이 편리한 곳이면 좋겠습니다.
시간은 금요일 저녁이나 토요일 오후로 생각하고 있습니다.

참가신청은 장소에 따라서 시간이 정해진 후에 따로 파이썬 마을에서 받을 예정이니 우선은 장소 대여가 가능한 분 있으시면 알려주세요 ^^;

FreeBSD도 이제 파이썬 디폴트 버전이 2.5입니다.

약간 늦은 감은 있지만, 오늘 드디어 파이썬 2.5.1이 디폴트로 바꾸었습니다.
그동안 2.4.4로 쓰느라 여간 답답하지가 않았는데, 7개월 정도에
걸쳐서 띄엄띄엄 작업해서, 오늘 겨우 넣었네요. 이른바 메가커밋!

지난번 버전까지는 저 혼자 모든 파이썬 관련된 작업을 했었는데,
이번 버전부터는 python@ 팀을 꾸려서 다른 팀원들과 함께 하고
있습니다. 처음에는 팀원들 중에 커미터가 아닌 사람도 몇 있었는데
워낙 기근에 허덕이는 커미터 구인난 때문에, 어느새 다 커미터가
돼 버렸네요. -o-;

파이썬 2.5가 나오고 벌써 9개월이나 지난 후에 된 것이라 지난 버전들보다 엄청 늦음에도 불구하고, 우분투 리눅스를 제외한 다른 오픈소스 시스템들에서는 여전히 2.4인 것을 보면, 2.4가 굉장히 만족스럽거나, 이제 파이썬 버전이 올라가도 그다지 개발자들 관심을 안 끌거나.. 지난 업데이트와는 좀 다른 것 같네요. NetBSD나 OpenBSD같은 경우에도 아직 2.4를 쓰고 있구요.

작업 도중 가장 힘들었던 것이, egg-info 문제인데, 갑자기 모든 distutils 패키지들이 엉뚱한 파일을 하나씩 다 설치하는 데 파일이름이 제각각이어서 수동으로 지정하는 방법 밖에는 없었습니다.
그래서 1000개에 달하는 파이썬 관련 패키지에 수천에 달하는 의존성 패키지를 다 가져다가 빌드해서 설치하는 파일 이름을 얻은 다음 그걸 적용하는 바람에 이번에 패치된 파일이 444개입니다.
총 7번의 포트 클러스터 빌드를 통해 검증한 덕에, 최종적으로 커밋된 포트에서는 초기에 발생했던 1000개 이상의 문제가 대부분 수정되었습니다.

그리고, Py_ssize_t 문제도 빠질 수가 없는데요, 파이썬 2.5부터 원래 int로 사용하던 크기 관련 변수들이 모두 Py_ssize_t로 바뀌는 바람에 amd64 같은 아키텍처에서 API가 안 맞아서 빌드하다가 죽거나 심지어 설치 다 하고 돌아가다가 죽는 문제가 발생했습니다. 가능한 한 많은 테스트로 수정을 하기는 했지만, 여전히 몇몇 패키지에서는 문제가 남아있는 것 같네요. 앞으로 보고되는대로 수정할 계획입니다.

이번 업데이트에서 (포트 측면에서) 수정된 사항들은 다음과 같습니다.

  • egg-info 지원 추가: 파이썬 2.5부터 distutils로 설치되는 모든 프로그램들이 egg-info파일을 설치합니다. egg-info 파일의 경우 웬만하면 고칠 일은 없지만, 필요한 경우 PYDISTUTILS_PKGNAME과 PYDISTUTILS_PKGVERSION으로 조절해서 이름을 맞춰줘야 합니다.
  • easy-install 지원 추가: 그동안 django를 필두로 해서 수많은 웹 관련 패키지들이 setuptools를 도입해 왔는데, 이번에 포트 전역적으로 setuptools지원이 추가되었습니다. USE_PYDISTUTILS= easy_install 로 적어주면 자동으로 egg위치 같은 것이 처리됩니다. pkg-plist에서는 %%PYEASYINSTALL_EGG%%로 해주면 egg 이름이 대체됩니다.
  • 디폴트 버전 마음대로 선택 가능: 지금까지는 포트에서 지정하는 버전 한 가지만 디폴트로 쓸 수 있었지만, 이제 PYTHON_DEFAULT_VERSION을 /etc/make.conf에 지정해서 디폴트 버전을 바꿀 수 있습니다. 아무리 세상이 바뀌어도 나는 무조건 2.3을 디폴트로 쓰겠다 하시는 분들도 편하게 2.3을 디폴트로 적용할 수 있습니다. 대부분의 경우에는 자동인식 되기 때문에 따로 설정할 필요는 없습니다.

불여우용 맞춤법 검사 확장 기능

예전에 미투데이에서 맞춤법 검사하기를 만든 적이 있었는데요, 그 이후에 종종 다른 곳에서 글 쓰면서 이거 맞춤법 검사하려니 상당히 불편하지 않은가! 하는 생각이 들어서, 아무 데서나 쓸 수 있게 불여우 확장기능으로 만들어 봤습니다.

물론, 전에 만들었듯, 그냥 그리스몽키 스크립트로 만들었으면 설치도 쉽고 더 좋았겠지만, 그리스몽키 스크립트로는 UTF-8과 CP949 사이 인코딩 변환을 할 방법이 도저히 없어서 결국 그냥 깔끔하게 직접 요청할 수 있도록 확장기능으로 만들 수밖에 없었네요.

간단하게, textarea 태그나 input 태그 중 텍스트 박스에서 오른쪽 클릭 하면 거기서 검사할 수도 있고, 아니면 본문 중 일부를 긁어서 오른쪽 클릭 하면 긁은 만큼만 검사를 할 수도 있습니다.

설치는 임시 위치로 [우리말 도우미 설치]를 클릭하시면 설치하실 수 있습니다. 라이선스는 원래 확장기능 소스 템플릿으로 쓴 프로그램이 GPL이라 GPL로 했습니다.

앞으로 계속 좀 더 정상적으로 보일 수 있게 불여우 애드온 사이트에 등록했는데 아직 공식적으로 인정받지 못했기 때문에, 많은 분의 평가가 필요합니다. 관심 있으신 분들은 사용해 보시고 아래쪽에 평가를 추가해 주셔서 나중에 공개 애드온이 될 수 있도록 성원해 주세요 +_+ (아직 모래통에 들어 있어서 반드시 자기 프로필 설정에서 show sandbox를 체크해야만 보입니다.)

점쏙옙 드디어 출판업계 진출

실험실에 웬 모르는 곳에서 잡지가 하나 와서 뜯어봤더니,
KIPA에서 발행하는 공개S/W리포트가 왔네요. 전에 기획사에서
블로그 글을 사용해도 되겠냐는 문의가 와서 동의했더니 잡지를
보내준 것 같습니다. 🙂 그 결과.. 지난 4월 19일에 쓴 “정겨운 깨진 한글들”이란 글이 인쇄매체에 실려서.. 결국 “占쏙옙”, “홰聆究셀”, “C>H3gGO” 등 어두운 곳에서 울고 있던 깨진 한글들이 인쇄되어 빛을 보게 되었습니다. -ㅇ-;

내용은 뭐 블로그에서 약간 추린 내용이라 그다지 새롭지는 않습니다. ^^;;

계산과학포럼을 소개합니다.

그동안 파이썬 마을에서 간간이 올라오는 생물, 지리, 물리, 화학 등 여러 분야의 과학 분야 질문들을 보고, 대덕단지의 여러 연구소에서 파이썬을 쓰는 분들을 만나뵈면서 급하게 뭔가를 하긴 해야하는데, 컴퓨터는 뜻대로 안 움직여주고 이런 경우를 겪는 연구자분들이 많이 계신 것을 느꼈습니다. 그렇지만, 아무래도 프로그래밍 언어를 전문적으로 하는 커뮤니티 같은 곳에서 계산 알고리즘이나 자료 처리 방법 자체에 대해서 설명하는 것도 애매하고, 오히려 의사소통이 더 어려워져서 서로 오해하는 경우도 생기고 하는 경우가 많았습니다.

그래서, 필요를 느끼고 계산과학포럼 이라는 커뮤니티 사이트를 새로 개설했습니다. 기존의 여러 프로그래밍 커뮤니티에서 뭔가 하고 싶은 걸 설명은 해야하는데, 설명하자니 배보다 배꼽이 더 크다고 느끼셨던 분들이나, 나와 비슷한 방법으로 다른 분야에서 일하는 사람들은 어떻게 하고 있는지 궁금한 분들은 오시면 좋은 자리가 되지 않을까 싶네요~
주변에 관심이 있으실만한 분이 있으시면 소개해주세요 +_+

질문이 나올 것 같은 몇가지 사항에 대해서 미리 언급해 드리자면,

  • 게시판 소프트웨어는 Vanilla라는 것을 썼습니다. 설치에 조언주신 BSDForum의 후회님 감사!
  • TeX나 BBCode, 테마 같은 것은 따로 공식 홈페이지에서 찾아서 깔면 됩니다.
  • 파이썬 포럼을 쓰려고 찾아보기는 했는데, 서버를 전용으로 쓸 게 아니라서 고정적으로 메모리 먹고 있기가 애매해서 결국 php로 된 것으로 썼습니다.
  • 지금 분류에 나타난 분야 외에도 IT분야를 제외한 프로그래밍을 사용하는 분야라면 포용하면 좋겠다고 생각하고 있습니다.
  • compsci가 원래 컴퓨터과학을 줄여 쓴 말로 더 많이 쓰이기는 하지만, 뭐 아무려면 어떻습니까. 🙂

여러 프로세스로 분산해 주는 제너레이터

요새 인텔에서 80코어 CPU를 공개할 정도로 점점 병렬 프로세싱이 싼 가격과 작은 크기로 내려올 것 같은 분위기가 많이 돌고 있습니다. 저도 요즘 학교에서 하는 실험이 CPU 20개에 분산해서 실행해도 하루 정도 돌아가는 것이다 보니, 컨커런트 프로그래밍이 기본적으로 지원되는 언어들에 대한 소식에 요즘 상당히 솔깃 하고 있는데요. 으흐흐 하여간 파이썬은 GIL 때문에 여러모로 불안할 따름입니다;

그러던 중, 파이썬 마을에 어떤 분께서 작업을 N개의 프로세스로 분산해서 실행하는 방법을 질문해 오셔서 답글을 달다가, 예제로 만들어 본 것이 보고 있으려니 제너레이터로 만들면 상당히 깔끔해 질 것 같아서, 잠시 제너레이터로 만들어 봤습니다. 흐흐

긴 시간이 걸리는 같은 종류의 작업을 여러 데이터에 적용하는 경우를 가정하고 만든 것인데요, 우선 용례를 보면 이렇게 하면 좋겠다 생각이 들었습니다.

보통 이런 것들은 threads.start_new_thread()처럼 뒤에 함수를 줘서 그게 실행되는 경우가 많은데, 그러면 조그만 작업도 다 함수로 만들어야 해서 코드가 왔다갔다 해서 헷갈리죠. 그래서 for루프 안에 넣었는데, 실제로 for 안쪽이 여러 번 돌지는 않고, 각각이 별도의 프로세스로 최대 4개가 동시에 돌아가게 됩니다. 그래서 이 인터페이스에 맞게 구현해 보면 요렇게..

이렇게 만들고 나니, 왠지 결과 데이터를 메인 프로세스에 모두 모아오는 기능이나 프로세스 재활용 같은 기능도 넣어 보고 싶고 with 절로 해 보고 싶기도 했지만.. 일단은 돌아가기에 귀찮아서.. 흐흐 -ㅇ-;; with로 하는 경우에는 for와는 다르게 메인 프로세스에서 하위 블럭을 생략할 수 없어서 메인 프로세스도 일을 해야하다보니 좀 더 복잡하겠더군요..

그런데, 사실 이걸로 열심히 놀고보니, 원래 쓰던 셸 스크립트로 하는 방법이 훨씬 간단한 것 같아서 허탈합니다. 하하;;;; ㅡ.ㅜ

웹앱스콘에 오세요~

6월 21일(목요일)에 삼성동 코엑스에서 웹앱스콘 2007이 열립니다. 주제는 요새 흔히 있는 웹2.0의 종합선물세트이지만, 아마도 참가비도 매우 싸고 프로그램도 오랜 시간동안 업계의 많은 분들이 노력해서 조절한 덕에 알찬 행사가 될 것 같습니다. 🙂

저는 프레임워크 2.2 워크샵 트랙에서 김창준님과 함께 전반적인 진행을 맡을 예정인데, 지난번 프레임워크 2.1에서 예고했던 대로, 이만용이사님의 TurboGears, 김승범군의 Seaside 가이드가 있을 예정이고, 덧붙여서 김창준님과 여러 분들이 분산 프로그래밍 언어인 Erlang으로 실시간으로 웹 프레임워크를 만들어가는 과정을 보여드릴 예정입니다.

전반적인 흐름은 지난번과 비슷하지만, 이번에는 전체가 따라해보기로 실습할 예정이기 때문에 모두 노트북을 지참하셔야하는 제한이 있고요~ 이제 인원 제한이 얼마 안 남았으니 참여하실 분들은 얼른 신청하세요~ 🙂

대화하는 사람들의 닉네임으로 현재 시간 추측하기

평소에 IRC를 항상 켜놓고 생활하다보면 종종 굳이 시계를 보지 않아도 IRC에서 어떤 사람들이 떠들고 있는지만 봐도 대충 시간이 얼마쯤 되었겠구나 생각할 때가 있습니다. 창문과 가까이 자리가 있는 사람들은 밖에 사람들이 지나가는 방향만 봐도 대충 시간을 알 수 있고, 차가 많이 보이는 곳에 자리가 있는 사람들은 교통 상황을 봐도 대략 짐작할 수 있는 거나 마찬가지로요~

그래서, 과연 이게 그냥 기분탓인지 실제로 경향이 강해서 쓸만한 지표인지 시험해 보려고 지난 몇 개월간의 IRC로그를 분석해서 떠든 사람 이름(!)과 횟수를 가지고 시간을 1시간 단위로 추측하도록 한번 통계내어 보았습니다.

우선, 예측 방법은 요새 인기가 하늘을 날고 있는 random forest를 사용했는데,
R에 들어있는 randomForest
모듈을 사용하기로 했습니다. party 패키지가 좋다는 얘기도 있지만.. 매뉴얼이 허술해서 사용법을 터득하지 못한 관계로 –;;

데이터는 HanIRC의 #perky에서 우선 IRC 데이터를 1시간 단위로 각 닉네임 별로 대화한 횟수(줄 단위)를 해당 시간에 모든 사람이 말한 횟수에서 나눈 값을 뽑았는데, 이 방법으로 과열된 상황과 심심한 상황을 대략 평준화를 할 수 있을 것 같고.. 해당 시간의 입력 벡터에 해당 시간의 데이터 뿐만 아니라 이전, 이후 시간의 것도 넣어서 연속성으로 추측할 수 있게 했습니다. 그래서 총 20명의 데이터를 이전, 현재, 이후 3가지 해서 60개 + 전체 대화량 3개 해서 63개의 실수 벡터가 들어갔습니다.

채널에 참여하는 인원이 비정기적으로 들어오는 분들을 포함하면 200명이 넘기 때문에, 여기서 입력 샘플로 20명만 추려서 사용했습니다. 물론 그 기준은 어느 정도 생활 패턴이 일정하면서 대화량이 적지 않고, 대상 기간에 생활리듬이 급격하게 변할만한 사건이 없었던 것으로 추정되는 분들을 골랐지요. 🙂

그래서, 이제 간단한 스크립트(로그파서, 데이터 가공)로 데이터 가공을 끝내고 이제 R에서 읽어서 쭈욱 처리했습니다. 노트북에서 했는데도 그다지 오래 안 걸리네요. (트리 수는 디폴트가 500개)

3,5월 자료로 트레이닝해서, 4월 자료로 테스트를 해 보면 다음과 같은 예측값 히스토그램을 얻을 수 있었습니다.

이것 보면 대략 오전은 거의 2시간 내외 오차로 썩 잘 맞히는 것 같고, 오후는 제법 오류가 많습니다. 특히 실제로는 늦은 오후 자료인데, 그걸 새벽 데이터로 오인한 경우가 많네요. 그리고 한낮 자료를 늦은 오후로 오인한 경우도 많고요. 역시 IRC사람들이 오전엔 아주 일정한 생활을 하는 반면에 오후에는 많이 바뀌는 것이 아닌가 싶군요!

각 시간에서 누가 얼마나 떠드는지가 더 의사 결정에 많은 기여를 했는지 알아보면 재미있을 것 같아서~ 그래프를 뽑아 봤더니 이렇게 나오는군요.

대충, 전체적으로 사람들이 얼마나 얘기하는가를 나타내는 prev, next, curr이 높고, 몇 명 평소에 상당히 규칙적인 생활을 하거나, 말을 많이 하는 분들이 상당히 점수가 높습니다. 시간별로 나눠서 보면, 새벽 0~6시 시간대에는 sakura님과 wooil님의 중요도가 아주 중요한데 패턴을 살펴보면 Sakura님이 말을 많이 하면서도 wooil님이 조용하면 새벽0~6시일 확률이 높다는 것을 알 수 있겠죠. 그리고 오전 9~10시 출근시간 무렵은 cocas님과 mithrandir님의 중요도가 높은데 일찍 일어나서 학교 가기전에 채팅하는 착실한 학생들(?)의 패턴이 아주 주효한 것 같습니다. -ㅇ-; 그리고 대략 저녁 6시 대의 중요도(variable importance)를 보면 퇴근시간이 일정한지 여부를 알 수 있을텐데요, 저녁 6시대에는 거의 높은 사람 없이 골고루 다 낮고, 정확도도 상당히 떨어지는 걸로 봐서는, IRC 사람들은 다들 불규칙한 저녁식사를 하는 모양입니다. -ㅇ-;

그 외의 또 다른 재미있는 지표로, outlier이라고 일반적인 패턴에서 벗어나는 샘플들을 골라내는 방법을 사용해서 상당히 평소와는 다르게 진행된 대화가 있나 한번 살펴보았는데, 3월과 5월에 대해서 outlier 지표를 그려보면 다음과 같이 나옵니다.

피크가 뚝뚝 떨어진 부분이 몇 군데 있는데, 이 부분이 평소와는 상당히 다른 일이 벌어진 경우를 의미합니다. 그래서 그 날짜를 구체적으로 로그를 살펴보면 정말로 평소하고는 아주 다른 일이 발생한 것을 알 수 있는데, 200주변(3월 12일)에는 평소에 밤에는 꼭 주무시는 wooil님이 새벽에 한참 대화를 하시는 이변이 발생한 날이고, 1200주변(5월 20일)에는 평소와는 달리 낮에 3시간동안 아무도 한 마디를 안 한 일이 발생했던 것입니다. 🙂

이제 대충 어느 정도는 정말 누가 말하는 지만 봐도 시간이 감이 오긴 한다는 것이 정량화가 되었는데요, 혹시 대화 패턴과 시간을 알면 요일도 알 수 있지 않을까 생각이 들었습니다. 그러니까.. 평소에는 낮에는 대화 잘 안 하다가 주말만 되면 S모 다방에 가셔서 하루 종일 IRC하시는 jachin님만 보면 일요일인지 당연히 알 수 있다던지 이런 것들도 정보가 되지 않을까 생각했는데, 의외로 통계를 내 보니까 거의 예측을 제대로 못하는게, 역시 IRC사람들은 주말과 평일 구분이 별로 없는 모양입니다;;

이 자료를 토대로 IRC 클라이언트 입력창 옆에 시계를 붙여 볼까 생각을 해 봤지만.. 너무 삽질같아서 포기.;; -ㅇ-;

파이썬3000 국제화 식별자(i18n identifier) 지원 결정

그동안 파이썬에서는 변수 이름, 함수 이름, 클래스 이름 등등에서 영문 알파벳과 숫자, 밑줄만 사용할 수 있었습니다.
전문 개발자들이야 영어가 필수이다보니 그냥 쓰면 된다지만, 어린 애들이나 도구로 프로그래밍을 하는 분들은
영어로 써야한다는 것이 엄청난 어려움으로 다가올 수 밖에 없습니다. 주석을 변수이름에 녹인다는 기법만 적용하려고
해도, 주석은 한글로 쓸 수 있다지만 변수 이름을 한글로 쓰지 못하면 녹여내지 못하고 결국 초딩용 코드 a, b, c가
등장하게 돼서 암호가 돼 버리죠 =.= 그래서 그동안 비영어권 국가 개발자들은 유니코드 식별자의 필요성을
계속 얘기하고 있었고, 한국, 중국, 일본 같은 경우에는 각각 비영어 식별자를 지원하는 패치를 배포하기도 했습니다.

그러던 중, Python3000을 위해 논의되어 왔던 파이썬 비-아스키 식별자 (non-ASCII identifier)가 지난 5월 27일에 드디어 통과되었습니다.
오랫동안 거의 “내 눈에 흙 들어가기 전에는…” 수준으로 비-이스키 식별자 (밑에서는 유니코드ID로 표기)를
싫어하던 귀도가 그동안 내 아들들에게도 자국어로 프로그래밍할 수 있는 기회를 주고 싶다는 마틴, 발터 등의
여러 비영어권 개발자들의 노력으로 설득당해버렸군요. 🙂 (물론 이 뒤에는 무려 메일 1000개가 넘는
여러가지 기술/정책/정치적인 토론이 있었습니다.)
아직 PEP에서는 상세하게 다뤄지지 않았는데, 일단은 PEP번호는
PEP-3131
입니다. (이렇게 내용 없는 PEP가 accept되기는 처음이 아닐까 싶은데, PEP로 정리만
되지 않았지 토론 내용 여기저기에 충분히 의견의 합의는 있었습니다.)

그럼, 한중일에서 그냥 2~3줄 패치해버리는 것으로 간단하게 됐던 한글 허용을 도대체
파이썬에서는 무엇때문에 이렇게 논란이 많은지 고민하실텐데요, 모든 문제의 원천은
소스파일마다 인코딩이 다른 상황 때문에 발생합니다. 소스코드끼리 인코딩이 다를 때
서로를 참조하는 방법을 통일시키려면 시스템 내부의 인코딩을 통일할 수 밖에 없는데,
이것으로 유니코드를 채택하다보니 유니코드에서 발생하는 여러가지 특징들이 문제로 다가오게 됩니다.
한중일의 패치는 그냥 허용 영역만 푼거라서, 사실 이런 것에 대해서는 대책없이 그냥 임시방편으로
풀어놓았던 것이지요.

대표적인 문제를 보자면, 우선 정규화(normalization)문제가 있습니다. 정규화는 똑같은 논리적
글자가 유니코드에서 여러가지 방법으로 표현되기 때문에 발생하는 문제인데, 예를 들어서
한글의 경우에는 “한(U+D55C)”과 같이 완성형으로 표현하는 방법도 있고, “ㅎㅏㄴ(U+1112 U+1161 U+11AB)”같이 조합형으로 풀어서 쓰는 방법이 있습니다. 앞과 같이 최대한 뭉쳐서 표현하는 방식을
NFC(Normalization Form C)라고 부르고, 뒤와 같이 최대한 풀어서 표현하는 방식을
NFD(Normalization Form D)라고 부릅니다. 둘 중 하나로 표현하면 논리적으로 같은 글자가
코드로도 똑같이 표현이 되니까, 코딩 방식을 다르게 했다고 이름이 같은지 모르는 MacOS X 파일시스템같은
상황이 없어집니다. 파이썬에서는 여러모로 내부 목적에 적합하다고 판단하여 NFC로 결정하였습니다.
사실 NFD와 NFC 사이에서는 간단하게 결정되었지만, NFKC와 NFC중에 무엇을 택할지는
좀 애매한 문제여서 토론이 있었는데, 결국은 손실 없이 최대한 줄여 쓰는 NFC를 채택하게 되었습니다.
(NFKC는 손실을 감수하고 줄여씁니다.)

그 외에도 역시 거의 유니코드 글자 속성 전 영역에 대해서 문제가 발생하는데, 이런 것이 있습니다.

  • Breaking: 각 글자가 앞 뒷 단어를 떼어주는 역할을 하는지 속성을 지정합니다. 예를 들어,
    한글{ZWNBS}메롱 이라면 “한글{ZWNBS}메롱” 전체가 한꺼번에 변수 이름이 돼야 하지만,
    한글{ZWBS}메롱 이렇게 썼다면 “한글” “메롱”이 따로 따로 변수 이름으로 인식돼야 합니다.
    (ZWBS=Zero-Width Breaking Space, ZWNBS=Zero-Width Non-Breaking Space)
    그런데, ZWBS같은 경우에는 눈에 안 보이기 때문에, 사람 눈으로 파이썬 소스를 완벽히 분석할
    수 없다는 문제가 발생합니다. 그렇지만, 이런 건 변태들이나 하겠지;; 하고 어쩔 수 없는 문제가
    아닐까 하는군요.
  • 글자 속성: 아스키 문자영역에 대해서는 몇 글자 안 되다보니, 어떤 것이 부호이고, 어떤 것이
    글자인가가 상당히 명확하지만, 유니코드까지 가게 되면 명확하게 숫자, 문자인 것이 있는 반면에
    어떤 것은 숫자인것 같기도 하고 아닌 것 같기도 한 것들이 수도 없이 많습니다. (예를 들어,
    홍콩지역 기수법 문자라던지, 네모 안에 숫자로 들어있는 것 같은 것들은 유니코드 데이터베이스에서는
    여러가지 속성이 같이 기록되어 있지만, 프로그래밍 언어 측면에서는 숫자로 인정해야 할지 변수 이름 글자로
    인정해야 할지 무지 애매하죠.. 10진법을 뛰어 넘는 숫자까지도 존재해서..) 그래서 각 글자 속성에
    대해서 어떤 것을 변수 이름으로 인정하게 하고, 어떤 것을 허용하지 않을지 결정하는 것이 중요한데,
    더욱 애매한 것은 유니코드 버전이 올라가면서 글자가 추가되거나 기존 글자의 속성이 바뀌는 경우도
    있다는 것입니다. -ㅇ-;; (그래서 파이썬에서 지원하는 유니코드 버전이 바뀌면 소스 파싱 방법도 바뀌고..)
  • 왼쪽으로 쓰는 문자체계: 아랍어나 히브리어 같은 경우에 오른쪽에서 왼쪽으로 쓰기 때문에,
    유니코드 처리에서도 상당히 특별하게 처리해 줘야 합니다. 여기서 이제 파이썬 소스코드를 보는 쪽 뿐만
    아니라 소스코드를 출력하는 부분이 있는 traceback이나 IDLE등 수많은 곳에서 오른쪽에서 왼쪽으로
    쓰는 처리를 해 줘야하게 됩니다.

유니코드 쪽의 문제 뿐만 아니라, 파이썬에서 유니코드ID를 디폴트로 허용할 것이냐, 소스쪽에서
옵션으로 풀것이냐, 아니면 파이썬 명령행에서 풀게할 것이냐 등등 디폴트 설정에 관해서 의견이
많이 있었는데, 이건 아직 의견이 팽팽하게 맞서고 있어서 결정되지 않았습니다. 심지어 어떤 사람들은
위에서 언급된 것들 (NFC냐 NFKC냐, 문자 속성 선택 등..)을 런타임에 결정할 수 있게 하자는
사람도 있는데.. 역시 사람들 의견은 정말 다양하군요 -ㅇ-;

그 외에도 여러가지 기술적 문제들이 남아있지만, 결국 정책적으로는 귀도가 파이썬의 내부
파이썬 코딩 스타일 가이드인 PEP-8에서
절대 파이썬 자체 코드 안에서는 ASCII 이외의 문자를 쓰지 말도록 정하였고, 광범위한 개발자들이
참여하는 모든 오픈소스프로젝트에서도 이 규칙을 채택하도록 권고하는 것으로 결정했습니다.

이제 파이썬3000이 나오면 왠지 교육용으로 추천해도 마음에 찔리는 게 없을 것 같아서 무척 좋군요! 🙂