매일 밥먹을 때 어느 식당을 갈까 엘리베이터에 서서 고민을 하게 되는데, 메뉴를 알게되면 좀 더 현명한 선택을 할 수 있지 않을까 해서, 학교 홈페이지에서 식단 제공되는 곳이 있나 찾아봤습니다. 오오. 생각보다 간단한 인터페이스로 2주 뒤의 메뉴까지 다 제공해 주고 있군요. +_+

그래서, 한번 파이썬 API로 만들어 봤습니다. 늘 쓰던 BeautifulSoup으로~

>>> from kaistfood import *
>>> menu = getmenu(u'동측')
>>> print ', '.join(menu[1])
쌀밥, 강낭콩밥, 감자양파국, 제육춘장볶음, 닭안심야채볶음, 고등어구이, 소시지전, 옥수수크로켓, 어묵야채볶음, 양배추쌈장, 참나물무침, 열무나물, 참치샐러드, 김구이
, 알타리김치, 배추김치
>>> menu = getmenu(u'학부', u'세트', 2007, 3, 29) 
>>> print ', '.join(menu[1])
김치햄볶음밥, 북어채계란국, 맛탱야채볶음, 숙주나물, 깍두기
>>> print ', '.join(menu[2])
오징어덮밥, 얼갈이된장국, 시금치겉절이, 마늘쫑건새우볶음, 깍두기
>>> for (pos, opt), menu in itermenus(2007, 3, 29):
...     if u'과일탕수육' in menu[1]:
...             print pos, opt, '==> 탕수육 발견!'
... 
동측 카페테리아 ==> 탕수육 발견! 
서측 카페테리아 ==> 탕수육 발견!

매일 파이썬 띄우고 누르고 있을 수도 없고, 학교 홈페이지 들어가기도 귀찮으니 매일 보는 RSS로 띄워놓으면 좋겠다 싶어서 RSS로도 만들어 봤습니다. 흐흐 (동측, 학부, 서측) 매일 새벽 3시에 업데이트될 예정이니 필요하신 분 등록해서 쓰세요~

소스는 svn 곳간에서 받으실 수 있습니다~

Google 개인화 홈페이지에 추가한 화면

리더에 추가하기 버튼 모음

• 동측:
• 학부:
• 서측:

오늘은 자바로 된 간단한 프로그램 하나를 받아서 어떻게 컴파일할까 한참 고민을 했습니다. (자바 컴파일 하는 방법을 까먹어서;;) 소스를 보니 무지 간단한 것만 쓰고 별로 길지도 않아서, 얼마 전에 봤던 java2python으로 돌려 봐도 괜찮지 않을까하는 생각이 번뜩!

java2python은 java 소스의 기초적인 문법을 파이썬 문법으로 바꿔주는 것인데, API를 바꿔주지는 않는 간단한 정책을 취하는 놈입니다. 일단 까는데는 파이썬 2.5 이상이 필요하고, ANTLR 파서 라이브러리에 파이썬 지원을 추가해서 깔 줘야합니다. 파이썬 2.5 이상인 이유는 바로 그 A if B else C 문법을 썼기 때문이죠 --;

% j2py -i siRNArules.java > siRNArules.py
% tail -4 siRNArules.py
if __name__ == '__main__':
    import sys
    siRNArules.main(sys.argv)

이렇게 자바의 메인 클래스 형태는 그대로 바로 클래스로 만들고 그걸 끝부분에서 호출해 주는 형태로 만들어줍니다. 다른 부분도 거의 건조체 번역을 보듯 완전 1:1로 번역되어 있는데, FileStream이나 IOException같은 것도 원래 자바 이름 그대로 되어 있습니다. 그래도, +=나 ++가 안에 들어간 부분이나, API가 안 바뀐 부분 몇 줄 고치니까 그런대로 잘 돌아가네요. :)

자바 -> 파이썬 포팅하기가 너무 귀찮은 분들은 우선 이걸로 번역해 놓고 손을 보는 것도 괜찮은 방법인 듯 합니다~

한국정보보호진흥원(KISA)의 지원으로 리눅스 2.6을 위한 SEED 패치를 만들었습니다.

커널에 넣는 패치이기 때문에 주 목적은 파일시스템을 암호화하는 경우와 IPsec같이 커널에 스택이 있는 네트워크 프로토콜을 사용하는 경우입니다. 항상 이슈가 되어왔던 인터넷 클라이언트로써의 접근성 문제와는 거의 전혀 상관없다고 보셔도 무방합니다. ^^;

그런데, 사실 IPsec이나 cryptfs 양쪽 모두 SEED가 AES에 비해 성능이 좋은 편이 아니기 때문에, 개인이 SEED를 쓸 일은 거의 없을 것 같고, 금융결제원이나 국정원과 관련된 뭔가를 할 때 쓰일 것 같네요. (VPN업체들에서 SEED기반 IPsec을 주로 쓴다고 합니다.)

여하간, 리눅스에 익숙하신 분들은 한번쯤 컴파일하실 일이 있으시면 패치를 해서 해봐주세요~ :) modprobe seed; modprobe tcrypt하고 나서 dmesg를 봐서 seed 관련된 부분에서 모두 pass 했다고 하면 정상동작하는 것입니다. 특히 빅엔디안 머신이나 64비트, 쿼드코어 등등 독특한 환경을 쓰시는 분들 꼭 한번 도와주세요 -ㅇ-; (패치 리뷰도 대환영!)

리눅스에 첫 패치 보내서 들여보내는 작업이 끝나면, 지금 갖고 있는 어셈블리 코드도 적용해서 다시 패치를 보내고 그 다음에는 FreeBSD에도 넣어 볼 생각입니다~

미투에서 요즘 유행하는 me2app 분위기에 휩쓸려서 뭔가 나와야 할 것 같은 걸 하나 만들어버렸습니다. -ㅇ-; 처음엔 뭔가 재미있을 것 같아서 우다다다 코딩을 했는데, 알고보니 wooil님께서 미리 예견하셨던 것! (제 미래를 다음에 한 번;)

미투에서 제공하는 friends.xml을 이용해서 전체 회원들의 친구 관계를 분석했습니다. 긁은 것은 어제 오후 5시쯤이었으니, 그 이후에 가입하셨거나 친구가 되셨으면 이 글의 통계에서는 무효입니다. 흐흐;

우선 친구 관계에 있어서는 전에 링크 같은 책에서 전세계를 기준으로 했듯이, 다들 알고보면 가까운 사이죠. 미투 친구들은 평균적으로 4.39명 건너 친구들로 묶여져 있고, 가장 먼 친구들까지 해도 6명 안에서 친구입니다. 그러니까, 나-친구1-친구2-친구3-친구4-친구5-그친구 이렇게 하면 다 아는 사람이라는 것인데.. (써놓고 보니 꽤 먼 친구군요;;) 작은 사이트이지만 아직 이 정도 거리로 있는 것을 보면, 아직 친구가 그렇게 많지 않은 분들이 꽤 있는 모양입니다. :)

역시 미투 회원은 누구든 예상할 수 있듯, charlz님은 2다리만 건너면 모든 회원과 친구인데, 이건 charlz님이 유일하고, 역시 평균 거리 1.479, 친구의 친구수 627명, 친구 수 346명으로 모두 1위입니다. -ㅇ-

친구 수도 흥미로운데, 미투 친구들은 친구가 평균 13.27명, 친구의 친구까지는 평균 255.63명이 있습니다. 역시나 가장 많은 것은 charlz님이시지만, 친구의 친구까지 포함해도 3명밖에 안 되는 분도 있었습니다. :)

친구 수의 분포로 보면, 100명 이상인 분이 charlz, cn_, sumanpark, s2day, ncsoft, djsol, codian 모두 7분이 있군요. 그리고, 그 밑은 분산된 분포로 고루 내려오다가 15~22명 사이인 분이 집중적으로 많고, 친구가 1명이거나 2명인 분도 전체 회원의 35%가 넘었습니다.

자, 그럼 마케팅이나 고객 분석에서 널리 쓰이는 "이 시스템의 평균적인 사용자"를 뽑을 수도 있겠는데요. 통계를 계산한 모든 값에서 가장 평균에 가까운 값을 보인 분은 widyou님입니다. 활동이 많아서 매일 답글에 보이는 회원 외에 다른 분들이 서비스에 대해 어떻게 생각하고 있을지 엿볼 수 있는 분이 아닐까 싶네요~

마지막으로 여기서 사용된 통계 자료를 바탕으로 보통 제공되는 친구 경로 검색 서비스를 하나 웹에서 접근할 수 있게 올려 놓았습니다. ---> 미투 친구 찾아가기

알려두기: 혹시 통계 자료에서 본인의 자료가 원치않게 언급된 분들은 제게 알려주시면 삭제해 드리겠습니다.
알려두기2: 저는 미투 초대장이 없답니다~ -O-
알려두기3: CGI에서 css는 ikspres님의 것을 몰래 훔쳐다가 썼습니다. -ㅇ-;

오늘 OSNews에 파이썬으로 된 리눅스 배포판인 Pardus에 대한 소개가 올라왔습니다. 여기저기 언급이나 도메인 이름을 봐서는, 터키 사람들이 주축이 된 것 같은데, 놀랍군요. 우리나라도 이런 걸 하나 만들어야하는데.. 흐흐

어떤 식으로 파이썬을 썼는지에 대한 소개도 나와 있습니다. 젠투가 파이썬을 사용자에게 노출하지 않고 그냥 툴로만 사용한 반면, Pardus는 scons처럼 빌드 스크립트 자체를 다 파이썬으로 작성하게 했군요. 심지어 네트워크 설정, 업그레이드 시나리오, 부팅 스크립트까지도 파이썬으로 되어있는 것이 아주 멋있습니다. :) 그래 이제 하드웨어가 웬만큼은 빠르군요 흐흐.

파이썬을 도입하면서 있었던 문제로는 tarfile이나 zipfile모듈과 호환되지 않는 놈들이 어쩌다 하나씩 있었는데, 금방 고치기는 했다는군요. 그리고, 압축파일을 푸는 동안에 메모리를 너무 많이 쓰는 것도 문제였는데, 한꺼번에 다 읽어서 풀지 않고, 적당히 버퍼를 둬서 풀도록 고쳤다고 합니다. 주 로켈이 무려 tr_TR.UTF-8인데, 파이썬에서는 절대로 ASCII외에는 디폴트로 안 만들어주겠다는 정책을 취하고 있어서 불편하다고는 하지만, 뭐 돌아가는 방법이 있으니까.. ^_^

"아.. BeautifulSoup.py가 필요한 데 웹 브라우저 열기는 귀찮고.. 이걸 어쩌나.." 이런 비슷한 경험이 한 번쯤은 다들 있으실 겁니다. 저도 특히 BeautifulSoup.py랑 rename.pl 같은 것들이나, Python-2.5.tgz 이런 것 괜히 파일이름은 아는데 다운받으려면 검색하고 귀찮아서, 왠지 1줄이면 될 것 같아서 오늘은 작정을 하고 스크립트로 만들었습니다.

#!/bin/sh
USERAGENT='Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050609 Firefox/1.0.4'
wget -U "$USERAGENT" -O "$1" 'http://www.google.com/search?btnI=1&q='"$1"

썰렁~ 흐흐.. 그런데, 바이너리 파일들은 구글이 운좋은 예감으로 안 튕겨주기 때문에, 결국 그 파일이 링크가 달려있는 페이지로 가는 덕분에 저런 간단한 방법으로는 안 돼서 결국은 또 BeautifulSoup의 도움을 받아서 이렇게 만들었습니다. --; (일이 점점 커지네~)

대충 써 보자면~

% luckget Python-2.5.tgz
Feeling lucky with Python-2.5.tgz ...
Fetching from http://www.python.org/ftp/python/2.5/Python-2.5.tgz ...
done
% luckget BeautifulSoup.py
Feeling lucky with BeautifulSoup.py ...
Fetched from http://www.intertwingly.net/code/BeautifulSoup/BeautifulSoup.py
done
% luckget 1GNF.pdb
Feeling lucky with 1GNF.pdb ...
Fetching from http://www.rcsb.org/pdb/files/1gnf.pdb ...
done

그러나, 이름에서도 눈치챌 수 있듯, 재수없으면 안 되는 수가 있으니 너무 기대하고 쓰지는 마세요~ :->

% luckget rename.pl
Feeling lucky with rename.pl ...
No luck. :-P

예전 orkut 유행을 생각나게 하는 요즘 me2day 광풍에 저도 우일님께서 초대해 주셔서 가입했습니다. ^_^

마침 짧게 쓰는게 오픈룩 오른쪽에 예전에 붙어있던 "싹둑싹둑~" 자리에 대신 넣으면 좋겠다 생각이 들어서, 구글 리더에 등록하고 짠! 하고 봤는데, 글쎄 me2day의 RSS에는 제목에 날짜가 들어가 있어서, 제목만 봐서는 무슨 내용인지 전혀 모르겠더군요.. 흐흐.. 그래서 좀 고민을 하다가 RSS를 받아다가 제목만 넣어주는 CGI를 만들어서 구글리더에게 그 CGI를 바라보도록 했습니다.

혹시 필요하신 분들을 위해 소스를 올립니다~

#!/usr/local/bin/python
from BeautifulSoup import BeautifulSoup
import urllib

print "Content-type: text/xml; charset=utf-8"
print

soup = BeautifulSoup(urllib.urlopen('http://me2day.net/hyeshik/rss'))
for incident in soup('item'):
        descr = incident('description')[0].contents[0]
        incident('title')[0].contents[0] = descr

print soup

애자일 이야기에 올라온 7월까지만 일한다면?이란 글을 읽다가, 인용한 그림을 보고 흠칫 놀랐습니다. 어디선가 많이 본 패턴이 보이는데, 으흠~~ 일을 적게하는 나라들에 유독 FreeBSD에서 굉장히 활동이 많은 국가들이 집중되어 있던 것입니다! 그래, 일을 적게 시켜야 뭘 하든 할 것이 아닌가 싶어서 과연 근무시간과 오픈소스 활동과의 상관 관계에 대해 조사를 해 봤습니다. 뭘 조사하느냐를 결정해야 하는데, 메일링리스트를 보는 것도 좋겠지만, 메일링 리스트는 언어의 제약이 굉장히 많이 작용할 것 같아서 FreeBSD의 PR 데이터베이스를 쓰기로 했습니다. 아무래도, 그냥 패치만 보내도 되고 비교적 짧게 적어도 되니까 꼭 올릴 사람들을 올릴 것 같아서~ :)

그래서, 모든 PR 자료를 cvsup으로 받은 다음에 로컬에서 간단하게 뒤져서 분석했습니다. 너무 오래된 자료들은 빼기 위해서 #40000이후만 넣었는데, 40000번이 올라온 것이 대략 2002년 6월 정도 됩니다. 그 이후에 올라온 69374개의 PR 중에서 Received헤더와 From헤더를 토대로 보낸 사람이 사는 국가를 추정했는데, 미국은 FreeBSD 서버들이 미국에 있어서 IP구별이 힘들어서 통계에서 제외하였고, 영국도 알 수 없는 이유로 GeoIP로 검출되지 않았습니다. 결국 남은 것은 총 100개 국가에서 모두 46304개의 PR이 나왔고, 얘네들을 대상으로 분석하기로 했습니다. (사용한 스크립트)

FreeBSD PR수와 근로시간

우선, 대충 생각해 봐도 인구와 활동양은 비례하는 관계가 어느 정도 있을 것이기 때문에, 활동량을 국가의 인구(위키백과에 올라가 있는 최근 자료를 사용)로 나눈 것과 작업량의 상관 관계를 계산했더니 -0.54가 나왔습니다. 아주 높은 것은 아니지만, 그래도 적당히 상관관계가 있다는 것을 암시하는 것 같은 느낌이 오네요~ (위 그래프에서 대충 경향이 약간 있는 것 같죠? 'ㅇ')

그 외에도 생각해 보면, 먹고 살기 힘들면 오픈소스 하기가 힘들테니, GDP하고도 어느 정도 관련있지 않을까 해서 계산해 보니까 0.52가 나오네요. 그래서, 한 번 얘네들을 묶어서 예측할 수 있도록 식을 만들어 봤습니다. 우선은 대충 기분으로 이렇게~

Pr=FreeBSD PR수, W=근로시간, G=GDP, Pop=인구

선형 최소자승법을 쓸 수 있게 약간 풀고 넘기고 하면,

Pr=FreeBSD PR수, W=근로시간, G=GDP, Pop=인구

그래서, 이놈을 스크립트를 짜서 분석해 보면, 각각의 계수가 k1=-1.51, k2=14.7, k3=3135.7, k4=-30172.4 정도 나옵니다. (사용한 스크립트) log G가 보통 10내외 인 것을 감안하면, W는 -로 100내외 정도 영향을 미치고, log(GDP)는 상당히 많은 영향을 미쳤군요. 흐흐 역시 샘플이 적어서 식이 좀 이상합니다. -ㅇ-; =3=3

인구1000만명당 FreeBSD PR수와시간의 관계, (붉은색은 예측 기대값)

그래도 대충 그래프 보면 뭔가 보이긴 하죠? ;; 빨간색은 위에서 근사식으로 만든 것을 다시 적용한 값인데, 마음대로 이름을 OBFI라고 붙여봅니다. -O-; 대충 1000만명당 PR 개수 순으로 정렬했을 때, 일하는 시간은 증가하는 경향을 보이고 OBFI는 감소하는 경향이 나타납니다. (상관계수는 0.618)

대충 빨간색보다 파란색이 위에 있는 나라는 환경에 비해 오픈소스 (여기서는 FreeBSD) 활동이 많고, 반대의 경우에는 환경에 비해 활동이 적다고 볼 수 있겠습니다. 일본이나 독일이 오픈소스에서 그렇게 활동을 많이 하는 것 처럼 보여도, 그래프에서는 별로 튀어 나오지 않는 것이 사실은 인구빨인 게 들통났군요~ 그리고, FreeBSD가 유난히 강세인 덴마크와 네덜란드가 역시 예측된 값과 엄청난 차이를 보여주고, 한국과 멕시코는 역시 약세입니다. 그런데, PR을 대상으로 해서 그런지, 아니면 주로 유럽이 대상이라 그런지 생각보다 언어는 그다지 문제가 안 되는 것 같네요. 영어를 주로 쓰는 호주나 뉴질랜드라고 다른 국가들에 비해 특별이 더 튀거나 그런 경향은 없는 것 같습니다. 러시아나 중국이 끼였으면 좀 더 분석이 좋았을텐데 OECD자료이다 보니, 없는게 아쉽네요.

일을 많이 시켜서 오픈소스 못하는 우리나라~

인구 순으로 하면 우리나라도 OECD에서 상당히 높은데, 앞으로 S모기업이나 L모기업 같은 곳을 비롯하여 사회 전반적으로 사원들이 젊은 시절에도 좀 여유롭고 즐겁고 발전하는 삶을 살게 근로시간을 줄여주면 오픈소스 뿐만 아니라, 인문학도 살고, 좋아지지 않을까 생각해 봅니다. 회사일 말고도 재미있는 것이 얼마나 많은데~

소수의 자료만 갖고 작업한 것이라 통계적으로 그다지 정확한 편은 아니지만 너그럽게 글자만 읽은 셈치고 잊어 주세요 =3=3 흐흐

일러두기 -- 아일랜드와 아이슬란드도 인구가 너무 적어서 통계에서 제외했습니다.

이제 컴퓨터도 받고 대충 자리 정리가 끝나서 기념으로 집들이(?)를 한번 해 봅니다. ^.^ 대체로 다 선물 받은 것으로 가득차 있는 것이.. 역시 더불어 사는 인생입니다.;;;

오늘은 대전에도 눈이 무지 많이 왔어요~ 내일 눈싸움이라도 한 판 해야겠네요. 기대된당~ ^^

Brett의 소개글에서 ohloh에 대한 얘기는 처음 들었는데, 오픈소스 프로젝트에 관한 무지 재미있는 사이트를 발견했군요. +_+

예전에 FishEye 같은 프로젝트 소스 변화를 추적해 주는 곳이나, Coverity같은 소스 품질을 검사해주는 곳은 봤었는데, 여기는 골고루 짬뽕인데다가 디자인도 예쁘고 아주 호감이 갑니다. 으흣. (물론 Coverity처럼 무결성을 검사하는 것은 아닙니다.)

파이썬에 대한 페이지에 가 보면, 주석의 양이나, 코드 크기에서 추산한 유지보수 비용과 소프트웨어의 자산가치, 라이선스의 특성과 잠재적 문제점 같은 것도 알려주고, 코드의 변화에 대해서도 시각적으로 아주 예쁘게 보여주네요~

뉴스를 수집해서 보여주는 것은 BerliOS에서도 했던 것과 비슷한 것 같은데, 그래도 요새는 RSS가 많이 쓰여서 손은 좀 덜 가긴 하겠네요. CIA처럼 개발자별로 따로 통계를 내 주는 기능도 있는데, 이것도 CIA보다 예쁘게 나오는 것이.. 흐흐 아주 마음에 듭니다. 요새 몇달동안 전혀 커밋 안 한 게 들통나서 얼른 밀린 버그 목록을 좀 봐야겠습니다. --; -ㅇ- (저는 cjkcodecs의 무식한 데이터 양 덕분에 변경한 라인 수로는 6위 -.-v =3=3)

요즘 리눅스 사용자들은 창 들고 흔들흔들 정도는 해 줘야 화면이 좀 뽀대가 나는 것 같아서, 부러움에 한번 큰맘 먹고 Beryl을 깔았습니다.

일단 Beryl을 쓰자면 Xorg를 포트에 없는 새 버전으로 올려야 한다기에, FreeBSD 위키에 있는 설명을 보고, 실험 중인 git 곳간에서 포트를 받아다가 설치했습니다. 포트 전체를 다 갖다놔서 생각보다는 편하더군요~ 게다가 beryl도 포트로 만들어놔서 간단~ :)

결국 6시간의 빌드 끝에, xorg, gnome, beryl 모두 빌드하고, nvidia 드라이버를 적당히 세팅해서 올려서 이런 화면이 짠!

그러나.. 무엇이 문제인지, 클릭하면 거의 1분에 1프레임씩 지나가고 키보드로 우다다 쳐도 업데이트가 전혀 안 되다가 마우스 클릭 해 주면 그제야 10초 있다가 보여주고 그래서.. 눈물을 머금고 나왔습니다. CPU를 많이 쓰는 상태도 아니고, glx설정은 대체로 제대로 되어있는 것 같은데 이상하더군요..

혹시 투지가 있으신 분은 시도해 보시고, 성공하시면 방법을 알려주세요. +_+

==> 이후에 패치를 하나 추가해 주니까 멋지게 돌아다니네요 +_+ 와와~~~

제가 작년에 대학원 전공을 정한 이후 거의 만나시는 분들마다, 왜 열심히 하던 전산이 아니라 다른 걸로 하게 되었냐는 질문을 많이 하셨습니다. 사실 열심히 생각을 정리해서 정한 것이 아니라, 대충 엄부렁한 상태로 묘하게 끌려서 다가가게 되었는데, 여러차례 질문을 받으면서 답했던 것들을 생각나는대로 대충 모아서 글로 옮겨봅니다. ^_^

저는 현실적인 목표가 있는 것을 좋아합니다. 프로그램을 만들어도 가까운 사람이 무척 필요로 하거나 아니면 누가 칭찬해주거나 하다못해 저라도 잠시 필요해야 뭔가를 만들게 되더군용~ 그래서 지금까지를 생각해 보면 전산은 그 자체가 삶의 목적이었다기 보다는 주변 사람들에게 관심을 끌거나 칭찬받거나, 아니면 회사에서 붙어있기 위한 수단이었을 뿐이었다는 것을 느낍니다. 그래서 병역특례가 끝나가면서 전산을 오랫동안 계속 하려면 뭔가 새로운 목적이 필요하다는 생각에 허전한 마음이 많았습니다.

그리고, 사실 전산을 하다보면, 자기의 그런 목적을 자기가 정하는 것이 아니라 회사의 경영진이나 시대의 흐름, 커뮤니티의 환경에 따라서 결정이 되다보니, 정말 재미를 느끼는 목적이 아닌 것을 그래도 따라가야하는 경우도 생기고, 직접 결정한 것이 아니라 애착이 안 생기는 경우도 많고 그렇잖아요~ 예를 들어, 네트워크 전송 기술에 관심이 많아서 그쪽을 전공한다고 해도, 결국 사람들이 그걸로 뭐에 써먹을지는 모를 일이니, 시장의 눈치나 투자자의 눈치를 봐서 뭘 할지 결정해야 하고..

그런데 마침, 생물과 관련된 교양서를 여럿 읽고 있었기에, 결국 저도 그렇고 주변 사람도 그렇고 모두 사람이다 보니 누구나 생물에서 나오는 혜택을 직접적이거나 간접적이더라도 별로 멀지 않게 바로 느낄 수 있겠다는 생각과 소프트웨어만 해킹할 게 아니라 생명체도 해킹대상으로 좋지 않을까 하는 생각에 완전 매료되는 바람에 복학 뒤에 뒤늦게 생물 수업을 듣기 시작해서 결국 이렇게 되었습니다.

뭐 물론 새로 선택한 분야에서도 과정 중에 어쩔 수 없이 해야하는 내키지 않는 중간 단계가 없지는 않겠지만, 결국 적용되는 분야가 이제 70이 넘으셔서 귀도 잘 안 들리시는 외할아버지/할머니께도 "약 만들어서 사람들 치료하는 데 쓰이는 기술을 만들어요"라고 쉽게 설명할 수 있다는 점에서는 한동안은 열심히 노력할 수 있을 것만 같습니다. ^_^*

뒷이야기
실제로 그 대화는 이랬습니다. =.=;

퍼키군: 약 만들어서 사람들 치료하는 데 쓰이는 기술을 만들어요.
외할아버지: 아~ 약만든다고?
퍼키군: 아니요. 약만드는 사람들을 도와주는 기술을 만들어요.
외할아버지: 아~ 약사발 같은 것 만드는거여?
퍼키군: (차마 더 설명은 포기;) 아아 네 ;;;;;

최근 PyCon과 Google TechTalk에서 귀도가 Python 3000에 대해 발표하였습니다. Python 3000에 대한 것을 귀도가 모두 모아서 직접 소개한 것은 처음이라는 점에서 많은 사람들이 관심있게 지켜보았는데요, 동영상이 무려 1시간 30분짜리나 됩니다만, 금방 맛보실 수 있게 간단하게 요약해 봅니다. 그런데, 귀도가 최근에 무척 늙은 것 같더군요. 몇년 전부터 팀도 겉으로 보기에 급속도로 늙고 있어서 안타까움을 느끼고 있는데, 귀도도 이제 나이를 어쩔 수는 없네요.. 으흐..

파이썬 3.0은 언제 나올 것인가?

스펙을 규정하는 PEP("펩"이라고 발음하더군요)은 2007년 4월까지, 첫 알파 버전은 2007년 6월, 2008년 6월에 최종 3.0 릴리스 예정이라고 합니다. 2.6은 2008년 4월을 예정하고 있고, 그 후로도 필요하면 2.7을 내놓을 예정입니다. 2.6은 주로 3.0으로 넘어가기 위한 여러가지 기능을 제공해 줄 예정이라고 합니다. 아마도 2와 3 모두를 지원하는 코드를 쉽게 작성할 수 있도록 몇가지 기능이 백포트될 것 같네요.

구식 클래스는 없다

2.1에서 들어왔던 new-style class가 이제 디폴트가 되어서, 구식 클래스가 사라지게 되었습니다. 둘의 차이를 직접적으로 항상 느끼는 분은 많지 않겠지만, 사용상 몇가지 연산자 정의나 상속 순위 같은 데서 차이가 납니다.

print가 이제 함수

종종 print 뒤에도 괄호를 쓰는 분들이 있긴 하지만, print는 그동안 statement였습니다. 이제부터 print도 abs나 sort같은 일반 내장 함수가 되었습니다. 그 말은, print뒤에 항상 괄호를 해야 한다는 것이고, 대략 보면 이렇습니다.

print x, y		-> print(x, y)
print x,		-> print(x, end=" ")
print >>f, x	-> print(x, file=f)

물론 대부분의 경우에 이걸 자동으로 번역해 주는 스크립트를 샤샥 돌리면 해결되지만, 한 가지 경우에 호환이 안 된다고 합니다.

print "x\n", "y"

이런 경우 예전에는 y앞에 빈칸이 안 나왔지만, 앞으로는 y앞에도 빈칸이 들어간다는군요. 혹시 이것 원래부터 알고 계셨던 분도 있으시려나요? 파이썬에 이런 기능이 숨겨져 있는지는 저도 이번에 처음 알았습니다. -ㅇ-;

딕셔너리 뷰

예전의 토론에서는 딕셔너리의 items, keys, values가 모두 이터레이터를 리턴하도록 바뀌고, iter*는 없어진다고 얘기가 나왔었는데, 단순히 이터레이터를 리턴하는 것을 뛰어넘어서 새로운 타입을 리턴하도록 바뀐다고 합니다. 새로 리턴하는 것은 items와 keys의 경우 마치 set처럼 동작하는데, 원래처럼 내용을 보거나 훑을 수 있을 뿐만 아니라, 변경작업을 하면 원래의 딕셔너리에 반영도 할 수 있습니다. 반면에, values같은 경우에는 set처럼 변경작업을 하면 key로 뭘 넣을지가 모호하기 때문에, 그냥 읽기 전용이 된다고 합니다.

기본 비교 연산자의 동작 변화

이것도 많은 분들이 생각도 못했던 파이썬의 기능이 사라지는 것 같은데요, 파이썬에서는 그동안 객체의 기본 비교연산자가 모두 정의되어 있어서, 서로 다른 타입끼리도 말도 안 되는 비교가 가능했습니다. 예를 들어 dict와 list도 어느 놈이 크고 작은지 비교가 가능했고, 사용자가 정의한 클래스끼리도 비교가 됐죠. (기준은 타입의 이름과 메모리 상의 주소랍니다. 으흐흐;;) 덕분에 서로 다른 타입이 잔뜩 들어있는 리스트도 정렬이 가능했었는데, 이제부터는 기본 비교연산자가 TypeError를 뱉게 했기 때문에, ["x", 1].sort() 같은 것은 불가능하게 되었습니다. 일일이 정해줘야 합니다.

문자열이 유니코드로

이제 기본적으로 ""로 쓰는 str타입이 유니코드 기반으로 바뀌고, 기존의 8비트 옥텟의 연속열이 str에서 bytes라는 타입으로 바뀝니다. 이미 많은 분들이 이걸 듣고 긴장하고 계셨겠지만, 그 영향은 굉장한데, 이제 ASCII 파일을 읽어서 바로 대문자로 바꾸거나 그런 것은 불가능합니다. bytes는 bytes일 뿐 문자열이 아니므로 글자 취급도 안 하고, x가 bytes타입이라면 x[0]같은 인덱스는 str과는 달리 아스키 숫자를 리턴합니다. 아직 자세한 것은 많이 결정되지 않아서, 혹시 관심이 있으신 분들은 참여하실 여지가 있을 것 같네요.

유니코드기반 문자열로 바뀌는 것은 최근 추세를 따라가는 것이기도 하지만, 파이썬을 처음 배울 때 유니코드가 뭐고 문자열이 뭐고 일일이 변환을 손으로 해 줘야 해서 굉장히 겁을 주는데, 이걸 해결할 뿐만 아니라, 유니코드를 전혀 모르는 서구권 개발자들도 얼떨결에 국제화된 프로그램을 만들게 하는 계기가 될 것 같습니다.

파일 입출력의 변화

문자열이 유니코드가 됐기 때문에, 파일을 바이너리로 열 때와, 텍스트로 열 때가 달라야하는 상황이 왔습니다. 따라서, 바이너리로 열면 read()하면 bytes가 나오는 대신 readline같은 것은 불가능해지고 (bytes는 줄같은 것은 신경 안 쓰므로) 텍스트로 열면 str이 나오는 대신 인코딩을 지정해서 변환 과정을 중간에 거치게 된다고 합니다. 지금의 codecs.open를 생각하시면 되겠습니다~

int/long 통합과 나누기 연산

int/long이 원래 2.2에서 통합되어서 내부적으로 자동 변환이 되고 있지만, 이제 겉에서는 전혀 눈치챌 수 없도록 완전히 int 타입 하나로 통합한다고 합니다. 이제 long이란 없고 그냥 큰 숫자는 내부적으로 BigNum류 연산을 쓰고, 작은 숫자는 CPU의 숫자 타입을 씁니다.

그리고, 2.2였던가요? 그때부터 __future__를 통해 지원되었던, "true division"이 기본이 됩니다. 1/2해도 이제 0이 아니라 0.5가 되고 2/2해도 1이 아니라 1.0이 됩니다.

예외처리의 변화

그동안 많은 파이썬 개발자들을 괴롭혀 왔던 except E, v: 이게 드디어 exception E as v로 바뀝니다. 예외를 여러 개 잡으려고 exception E1, E2 썼다가 E2가 무시되는 바람에 멀쩡히 돌던 프로그램이 퇴근만 하면 죽는 낭패를 봤던 경험이 있는 개발자들이라면 모두 쌍수를 들고 환영할 것 같네요. ^.^ 또한, v가 그동안 try except 블럭 스코프가 아니라 그 외부의 스코프에 속해서 지워지지 않아서 try-except가 반복되다보면 메모리가 모자랐던 끔찍한 혼란이 드디어 해결됩니다. except 블럭도 스코프를 만들어서 except 블럭이 끝나면 v가 사라지게 되었습니다.

인자 시그너처 표시

C++이나 자바에서 넘어온 프로그래머들이 그렇게도 원하던 기능! 함수 인자에 타입 선언해 주기 비슷한 것이 추가됩니다. 정확히 말하자면 타입 선언이 아니라 그냥 인자 이름 옆에 """ 로 주석 쓰듯 뭔가 데이터를 넣어주는 것 뿐이고, 함수이름 밑의 속성으로 접근이 가능합니다. 이걸 활용해서 타입을 체크하거나 범위를 체크하는 데코레이터를 만들 수 있겠죠.

키워드만 받는 인자

그동안은 키워드 인자를 받도록 선언해 놓아도 왼쪽부터 순서대로 채워지기만 하면 키워드 인자까지 넘어와가지고 되는 경우가 있었는데, API 디자이너의 의도를 충분히 살려서 혼란을 없애고 싶은 경우를 위해, 키워드로만 받는다고 선언하는 문법이 생깁니다. 좀 문법이 희한한데,

 def foo(a, b=1, *, c=42, d): …

로 쓰면, c와 d는 키워드 인자로만 받는다는군요;;

집합(set) 표기법

2.4에서 추가되어 굉장한 인기를 끌고 있는 set이 드디어 소스에서도 간단하게 쓸 수 있게 표기법이 추가됩니다. {1, 2, 3}으로 쓰면 set이 된다고 합니다. 즉, :가 없으면 set, :가 있으면 dict가 되는 것이죠. set comprehension도 물론 생깁니다. 흐흐

 {f(x) for x in S if P(x)}

절대경로 임포트

파이썬 2.5에서 __future__로 숨겨져 있는 기능인데, 이제 패키지 경로의 혼란을 줄이기 위해서 패키지 내부에서 암묵적으로 상대적인 경로로 임포트가 가능하던 것이 금지됩니다. 이제 상대경로로 임포트를 하려면 . 이나 .으로 시작되는 다른 경로 이름을 써 줘야 하게 되었습니다.

문자열 포매팅

2.3인가에서 추가되었던 string.Template가 이제 표준 str타입의 % 연산자에서 지원되게 됩니다.

 "See {0}, {1} and {foo}".format("A", "B", foo="C")

여기서 하나 궁금해 지는 것은, string formatting에서 항상 나오는 복수형 만들기 문제나 조사처리 같은 것을 써드파티에서 추가할일이 생길텐데요. 그런 경우를 위해서 사용자가 타입별로 제어할 수 있게 하거나 훅을 넣을 수 있게 여러 기능을 제공할 것 같습니다.

새로운 scope 선언자 nonlocal

파이썬 2.1에서 nested scope가 들어오면서 무척 편해진 것은 사실이지만 그동안 global과 local 밖에 없어서 상위 스코프가 global이 아닌 경우 상위 스코프의 뭔가를 건드리려면 list로 만들어서 넣는다던지 편법을 써야 했습니다. 이걸 위해서 스코프 블럭 앞에 nonlocal이라고 선언하면 이쪽에서 쓸 것은 아니니 nested된 윗쪽 스코프 것을 건드려라 하게 됩니다. 말로 들으면 복잡한데 실제로 사용한 예를 보면 나쁘지 않군요. :)

 def outer():
    x = 42
    def inner():
        nonlocal x	# <---- new
        print(x)
        x += 1
    return inner

switch/case ?

이 기능은 많은 사람들이 아주 옛날 1.4 시절부터 간절히 바라던 기능이고, 패치도 무척 많이 나왔는데, 결국 귀도가 PyCon에서 거수로 3.0에서도 안 넣겠다고 장난스럽게 결정했습니다. 흐흐. 아마도 귀도가 switch-case 싫어하는 것은 정말 오래전부터 일관적이었던 것이라서, 앞으로도 당분간은 들어갈 일은 없을 것 같네요. (파이썬에서 switch/case를 지원하는 것은 생각보다 많은 모호점을 만들어냅니다. 한 10분만 생각해 봐도 끔찍해서 그만 생각해야겠다고 덮어두게 되죠;)

그 외의 자잘한 변화

• exec가 print와 마찬가지로 키워드에서 빠지고 내장함수가 됩니다.
• range 내장함수가 xrange로 대체됩니다.
• input 내장함수가 raw_input로 대체됩니다.
• zip 내장함수가 이터레이터를 리턴합니다.
• intern 내장함수가 sys 모듈로 이사갑니다.
• __nonzero__ 오퍼레이터 이름이 __bool__이 됩니다.
• 파이썬 2.5에서 추가됐던 with가 3.0부터는 디폴트로 키워드가 되고, as도 마찬가지로 키워드가 됩니다.
• ``로 repr()할 수 있었던 것이 이제 불가능합니다. code golfer들에게는 슬픈 소식이네요.
• <> 연산자가 없어집니다.
• apply 내장함수가 없어집니다.
• coerce 내장함수가 없어집니다.
• dict.has_key 메쏘드가 없어집니다. 2.3부터 in 연산자로 대체되었죠.

그 외의 주요한 변화

지금 거의 단일 단계로 쫙 펼쳐져 있는 라이브러리들이 Java나 .NET처럼 체계화된 모양을 어느정도는 갖추게 될 예정인데, 많은 사람들이 지금 토론중입니다. 그리고, C API도 변화되게 될 것이지만, 가장 큰 문제로 지금 많은 함수들이 char*을 받고 있는데, 문자열이 유니코드로 바뀌게 되어 버렸으니, 이걸 어떻게 적용할지 고민이 되게 될 것 같네요. 원칙은 함수를 추가하거나 지우기는 하겠지만, 원래 있던 함수나 API에서 인자 개수만 바꾸거나 타입만 바꾸는 일은 없을 것이라고 합니다. 이렇게 되면 컴파일러 에러로 대부분 다 깔끔하게 잡아낼 수 있겠죠.

오늘 파이썬 3000을 위해 할 수 있는 일

웬만한 것은 자동으로 변환할 수 있게 될 것이니, 걱정할 필요는 없고, 지금부터 짜는 소스는 파이썬 3000에 대비하여 호환성 있는 코드를 짜도록 노력해야 합니다.

• 파이썬 2.6이 나오면 2.6을 사용합니다.
• 최대한 기존의 코드 전체를 커버하는 유닛 테스트를 작성합니다.
• dict.keys()를 되도록 sorted(d.iterkeys())로 씁니다.
• list타입이 넘어오는 것이 진짜로 필요한 경우에는 list(d.iterkeys())를 씁니다.
• 모든 exception을 Exception클래스에서 상속 받도록 합니다.
• 모든 클래스를 object 클래스에서 상속 받도록 합니다.
• int끼리 나누는 경우에 // 연산자를 사용합니다.

기다릴 수 없어!

파이썬 3000 기다리기가 정말 괴로우시겠지만, 항간에 떠도는 "파이썬 3000도 펄6 꼴 날거야" "파이썬팀이라고 별 수 있나 보나마나 계속 매번 6달씩 연기한다고 발표하다가 결국 5년 걸릴걸?" 이런 소문들은 거의 현실이 될 것 같지 않습니다. 귀도가 하겠다고 한 것은, 정말로 거의 금방 이룰 수 있는 것만 공약하고 있으며, 언제 끝날지 모르는 대공사는 최소한으로 줄여서 몇 개에 불과합니다. 정말 멋진 게 하나 나올 것 같지 않습니까? 매일 기다리기 지루하시면 달력에 2008년 6월까지 남은 날짜를 계산해서 X표시를 하면서 기다려 보세요. :)

더 관심이 있으신 분들을 위해 ==>

• 파이썬 3000에 대한 구글 TechTalk 비디오
• PyCon 2007에서 발표된 귀도의 기조연설 프리젠테이션