파이썬 페차쿠차를 마치고~

파이썬 페차쿠차를 마치고 막 대전에 돌아왔습니다. 오늘은 비도 계속 추적추적 내리고 주말 저녁이기도 해서 걱정이 좀 됐었는데, 90%를 훨씬 넘는 완벽한 출석률로 좋은 시간 가졌습니다~

이번 페차쿠차는 12장으로 줄이고 첫 장, 마지막 장의 시간 제한을 없애는 약간의 변형을 거쳤는데, 원래 예상했던 것 보다 훨씬 다들 준비를 많이 해 오셔서 이렇게 짧은 시간에 많은 얘기를 들은 적이 있을까 싶을 정도로 압축적인 경험 전달이 된 것 같습니다. 다들 어쩜 말씀을 잘 하시는지 그냥 말 하셔도 20초에 딱 맞을 것 같은 분들도 있고.. 🙂 — 사실 중간에 잠시 생각했던 대로 50명 이상이 참가하는 행사로 키웠으면 발표하는 분들에게 부담감이 좀 가서 제대로 진행되지 못했을 것 같다는 느낌이 들었습니다. 이번에 페차쿠차 경험을 좀 쌓았으니 다음에는 더 크게도 할 수 있을 것 같네요!

우선 정말 다양한 (하나도 겹치는 분야가 없었어요!) 분야에서 파이썬을 쓰시는 분들이 모여서 얘기하다보니 쓰이는 곳을 알았다는 것 뿐만 아니라, 앞으로 뭔가 궁금한 게 있으면 누구한테 물어봐야할 지 알았다는 것도 참 유익했습니다. 회사에서 파이썬을 도입한 과정이나 문제해결 과정을 조금씩 엿볼 수 있었던 것도 다른 곳에서 파이썬을 도입하는 데 어려움을 겪고 있는 분들께 전해주기 좋은 경험이었던 것 같네요.

형식적으로는, 20초는 매우 적절한 시간이라는 느낌을 받았고요, 보통 20초면 시간이 좀 모자라거나 남을 때도 쉽게 따라잡거나 약간 덧붙여서 유연하게 넘어갈 수 있는 아주 좋은 간격인 것 같네요. 그리고 시간 제약이 정확히 있다보니 지나치게 구체적인 설명은 아무래도 피하게 돼서, 대부분이 집중해서 관심있게 들을 수 있고, 질문할 시간이 잊기 전에 오기 때문에 대화를 시작하는 역할까지도 하게 돼서 좋았습니다. 12장도 이번 주제에서는 적절했던 것 같은데, 기술적인 내용 같은 경우에는 어떨지 아직 잘 감은 안 오네요.

이번에는 발표가 모두 13분이 하셨기 때문에 미리 짜면 아무래도 페차쿠차는 처음이라 긴장도 되고 할 것 같아서 아예 순서를 알 수 없게 파이썬의 random.shuffle()을 써서 순간순간 자동으로 슬라이드가 열리게 했습니다. 🙂

중간에라도 온 사람 이름을 입력한 다음에, 엔터를 치면 “누구님 하세요!” 하면서 그 사람의 슬라이드를 열어줍니다. ^^; 다음에 누가 할 지 모르기 때문에 긴장 없이 들을 수 있습니다.;;; (뒤에 남은 분들은 약간 -ㅇ-)

슬라이드는 이번에 파워포인트, 키노트, 임프레스 세가지 포맷 중 하나로 미리 이틀 전에 제출받았는데, 동영상 출력 기능이 가장 적절한 키노트로 모두 변환한 다음 키노트에서 20초 자동넘김 지정을 해서 QuickTime 동영상으로 만들었습니다. 미리 변환을 동영상으로 주우욱 해 뒀던 건 아무래도 4분이 짧기 때문에 발표자가 바뀔 때 빨리 바뀔 수 있게 한 것인데 괜찮았던 것 같네요.

이번에 발표 동영상은 미지리서치의 도움으로 촬영을 하기는 했지만, 테이프에 문제가 좀 있어서 앞부분 반 정도만 촬영이 제대로 되었구요. 발표자분들이 요청하신 기업기밀보호(^^;)를 위해 편집한 다음에 공개할 계획입니다.

파이썬 뿐만 아니라 분야별, 기술별, 모임주제별 다양한 페차쿠차들이 많이 생기면 좋겠네요~

파이썬마을 페차쿠차 – 파이썬 경험 나누기

얼마 전에 파이썬 마을 모임에 대한 얘기를 올리고 많은 분들이 관심을 보여 주셨는데, 제가 한동안 재미있는 삶에 빠져서 놀다가 깜빡해서;;
좀 정리를 해서 구체적인 일정을 정했습니다. ^_^

멍하니 있으면 순식간인 단 48분 만에 다른 12명의 파이썬 경험을 압축해서 빨아들일 수 있는 기회!

지난 번 댓글에서 파이썬에 처음 입문하시려는 분들도 많은 관심을 보여주셨지만,
아무래도 이번에는 경험공유에 강조하기로 했기 때문에, 경험만 알짜배기로 모아서
얘기를 하는 쪽으로 하고 다음에 또 다른 좀 더 큰 모임에서 튜토리얼 섹션 같은 것을
마련하는 쪽으로 마음 먹었습니다. 조만간 꼭 하겠습니다~ 🙂

참가 신청은 온오프믹스에서 모레 (수요일) 부터 받을 예정입니다.

모임의 주제는 “나는 파이썬을 이런 데 쓴다!”이고, “참가자 모두가 발표해야합니다.” 발표의 내용은 경험을 나누는 것이 주가 되며, 기술적인 상세사항이나 기술 자체에 대한 것들은 되도록이면 지양합니다. 참가 신청에 발표 제목을 꼭 표시해 주세요.

  • 일시: 8월 22일(금) 오후 7시 – 삼성동 미지리서치 본사 2층 회의실
  • 신청 기간: 8월 13일(수) 오전 10시 ~ 8월 18일(월) 오전 10시 (12명)
  • 참가대상: 파이썬으로 뭔가를 작업해 본 경험을 나누고 싶으신 분
  • 참가비: 없음 (저녁식사 제공되지 않음, 얼음물/아이스커피믹스 무한제공 ^^)
  • 모임은 모두 한국어로 진행됩니다

발표 주제의 예:

  • 나는 파이썬을 일상 생활에 사용한다.
  • 휴대전화기에 올라간 파이썬
  • 우리 온라인 게임은 서버가 파이썬으로 되어 있어요.
  • 알고보면 기상예보 파이썬으로 한답니다. (쿠당~)
  • 우리 아기 교육은 파이썬으로: 동요 따라부르기, 숫자 놀이
  • 우리 회사 서버는 파이썬을 지우면 대형사고가 난답니다.

발표형식은 경험 공유를 하다가 따분해질 수도 있기 때문에, 디자인계에서 많이 사용하는 발표형식인 “페차쿠차“를 차용했습니다.

  • 모든 발표는 슬라이드(파워포인트, 키노트, pdf 등) 12장으로 구성돼야 합니다.
  • 각 슬라이드는 20초가 지나면 발표자의 의지와 상관없이 자동으로 넘어갑니다. 되돌아갈 수 없습니다. -> 20초 * 12장 = 4분
  • 자동으로 넘어가는 것을 감안해서 슬라이드는 간결해야하고, 모임 목적이 경험 공유이기 때문에 구체적이기 보다는 개괄적이고 재미있는 경험 위주로 구성해 주시면 좋습니다. (보통은 그냥 관련 그림만 말 순서대로 쭉 붙여 넣으시면 됩니다.)
  • 발표 자료는 모임 일자 이틀 전에(8월 20일 밤 11시 59분까지) 모임 주최자에게 보내주셔야 합니다.
  • 생각보다 20초에 맞추는게 만만치 않기 때문에, 미리 연습해 보시고 오시는 것이 다른 사람들과 경험을 효과적으로 나누는 데 좋습니다. ^^

그럼 전국의 파이썬 강호 여러분을 많이 뵈었으면 좋겠네요!

파이쿠차 -오랜만의 파이썬 마을 모임!

다음 주(7월 27일-8월 2일)에 오랜만에 애자일 개발 워크샵 일로 1주일 동안 서울에 머물게 됐습니다. 그래서 서울 방문 기념으로 거의 1년 만에 파이썬 마을 모임을 한 번 하려고 합니다.

지난 번에 다른 행사의 부대행사로 파이썬 관련 세션을 하나 생각하면서, 자기가 파이썬을 쓰는 분야에 대해서 얘기하고 토론하는 걸 좀 생각해 봤었는데요. 최근에 페차쿠차라는 걸 보고 한 번 “내가 파이썬을 쓰는 곳/파이썬으로 만든 것“을 페차쿠차 형식으로 한 번 해 보면 어떨까 생각했습니다.

페차쿠차는 발표 포맷이 정해져 있는데요, 슬라이드 20장을 각 20초 씩 해서 총 6분 발표를 해야합니다. 보통 많은 사람들이 발표하는 곳 가면 거의 반 정도는 발표하는 사람을 제발 끌어내리고 싶은 유혹을 받는데 그런 걸 줄이기 위한 포맷이라고 하네요. 그래서 이번에는 20장은 보통 엄청 오래 한 분 아니라면 회사 기밀까지 나와야할 것 같아서, 12장 * 20초 해서 4분으로 하면 좋을 것 같네요. 중요한 것은 슬라이드는 자동으로 넘어가니까 한 슬라이드에서 시간을 마음대로 조절해서 쓸 수는 없다는 게 페차쿠차의 기본 원리라고 합니다. (다양한 분야에 활용하시는 분들이 참석하셔서 경험을 나누시면 좋겠습니다!)

혹시 장소나 시간에 대해서 좋은 생각이나 제안 (또는 장소제공) 등 남기실 말씀이 있는 분들은 알려주세요. ^^ 대략 인원 추산도 해야하니 참석하실 수 있는 분들 답글 남겨주시면 고맙겠습니다~

인스턴스 복사를 직접 다루기

종종 한 인스턴스를 대량으로 복제해서 약간씩 바꿔야할 일이 있습니다.
주로 진화 알고리즘 계열이나 고치기 전/후를 비교해야하거나, 엄청나게 바꾼 뒤에
롤백을 해야한다는 등의 경우가 그런데요.
파이썬에서 복사는 기본 타입들은 각각 독특한 방법이 있지만, 보통은
copy모듈을 쓰면 간단합니다.

그런데 철학적(?)인 분위기를 잡으며 경험이 조금 더 많은 사람이 쓱 나타나서
“너 깊은 복사랑 얕은 복사 알아?”라고 할 것 같은 느낌이 언제나 copy
쓸 때마다 들곤 하죠; 깊은 복사(deep copy)는 참조하고 있는 객체 모두를
복사하기 때문에 속성으로 들어있는 놈들까지 별개의 인스턴스가 돼서
완전히 떨어집니다. 얕은 복사에서는 참조는 복사하지 않고 자신만 복사하기 때문에
리스트같은 것들이 공유가 되는 특징이 있습니다. 물론 얕은 복사가 훨씬 빠르고
자원을 효율적으로 쓰겠죠.

그런데 종종 클래스를 만들다 보면 어떤 것은 깊숙히, 어떤 것은 얕게 해야할 일이
발생하는데요. 그러면 copy.copy를 쓸 수도 없고 copy.deepcopy를 쓸 수도 없고
애매한 상황이 됩니다. 결국은 얕은 복사를 한 다음에 수동으로 깊은 복사를 해 주면
되겠죠. 그래서 좀 더 복사 과정을 자세히 다뤄보도록 하겠습니다.

우선 복사를 하려면 인스턴스를 새로 하나 만들어야 합니다. 여기서 발생하는 문제!
__init__가 호출되면 복사라고 부르기가 애매하겠죠. 이미 초기화된 놈을 다시 초기화하게 되니까..
그래서 __init__는 호출하지 않고 그냥 객체만 생성하는 방법을 써야하는데,
신형 클래스(new style class)냐 구형 클래스(old style class)냐에 따라서 방법이 다릅니다.

신형 클래스는 __new__를 쓰면 됩니다.

구형 클래스에서는 types.InstanceType을 쓰거나 types 모듈 불러오기가 귀찮으면 type(s)
써서 만들 수 있습니다.

그래서 일부만 복사하는 놈을 만들어 보면

이렇게 a는 복사되고, b는 공유되는 방식 copy()를 만들 수 있습니다.

사실 파이썬 자체에서 pickle 모듈같은
곳에서 저장/복원을 위한 속성 저장법이 있는데, copy
모듈도 같은 방법을 지원합니다.

__getstate____setstate__ 중 하나만 구현해도 상관은 없는데 그렇게 하면 리턴값이나 받아오는
값이 모두 딕셔너리가 돼야합니다. 위에서는 a는 그대로 참조만 가져오고, bc는 복사하는
방식으로 클래스 복사 방법을 지정해 줬습니다. 복사와는 크게 관련은 없지만 pickle에서
저장할 수 없는 속성들 (예를 들어 소켓 같은 것)이 들어있는 클래스는 __getstate__를 지정해 주는
방식으로 특정 속성을 저장에서 뺄 수 있습니다.

파이썬 3의 한글

따로 말은 필요없고 직접 예제로!

캬~~

관련 참조:

“파이썬은 멀티코어 줘도 쓰잘데기가 없나요?”에 대한 파이썬 2.6의 대답

바야흐로 초딩도 멀티코어로 오락하는 시대가 오면서 이제 파이썬 GIL 공포가
많은 사람들을 위협하고 있었습니다. 그에 대한 해결책으로 예전부터
병렬 프로그래밍을 위한 여러가지 프레임워크, 예를 들어
MPI, CORBA, PyRO 같은 것들이 나왔지만, 다들 멋있게 모든 걸 포용하는
라이브러리를 만들다 보니 설치가 어렵거나 배우는데 한참 걸리는 게 결국 문제가
돼서 실제로 심각한 개발자 아니면 그냥 “CPU 1개면 충분해요”라고 눈을 반짝거리며
스스로 최면을 걸고 있었던 것이 사실입니다~

그래서 GIL의 파이썬 프로젝트 자체에서의 해결책으로는 공식적으로 결론에 도달한
것은 아니지만 Adam Olsen의 GIL없애기 프로젝트 같은 것도 있었는데,
이번에 몇몇 사람들의 강력한 후원으로 파이썬 2.6과 3.0부터
pyProcessing이 새 이름 multiprocessing
으로 표준 라이브러리로 들어오게 되었습니다.

pyprocessing의 다른 병렬 처리 라이브러리들에 대한 장점은
뭐니뭐니해도 표준 threading 모듈과 API가 같다는 점이겠죠. threading으로 기존에 짜 놓은
프로그램을 그냥 모듈 이름과 클래스 이름 아주 약간만 바꿔주면 쓰레딩 대신 멀티프로세싱을
사용하게 되어서 결국에는 멀티코어를 제대로 쓰는 프로그램이 됩니다. 실제로
쓰레딩같이 모든 변수를 공유하는 것은 아니고, 리턴값만 전달을 받기 때문에
정확히는 좀 다르다고 볼 수도 있지만, 뭐 “그렇게 짜면 왕변태”라고 선언하면 되겠죠. ㅎㅎ;

그래서 실제로 쓰는 모양을 보려고 옛날에 유행했던 정규식으로 소수 검사를 하는 걸 한 번 돌려 봤습니다.

보시면 threading으로 만든 모듈과 join, start, worker 등의 사용법이 같아서 그냥 쉽게 바꾸실 수 있는데, 이렇게 돌려보면 대략 시간이 듀얼코어에서는 이렇게 나옵니다.

대략 2배 정도 빨라졌죠~ 그냥 고전적인 던져주고 실행해서 리턴받는 방식 말고 보통
실제로 더 많이 쓰는 Queue 모델로 일꾼을 코어 개수만큼 돌려보면 이렇게 할 수도 있습니다.

시간은 대략 9초 정도 듭니다. 그리고 fd 넘겨주기를 지원하는 플랫폼들에서는 소켓도
받아다가 넘길 수가 있으니 네트워크 프로그램도 간단하게 멀티코어를 쓸 수 있습니다.

아주 간단하게 멀티코어를 쓸 수 있는 장점으로 표준 라이브러리로 도입이 되긴 했지만,
아직 문제가 몇 개 있는데요. 대표적으로 FreeBSD에서는 아직 POSIX 1003.1b 세마포어를 “제대로” 지원하지 않기 때문에 FreeBSD에서는 Queue나 Lock등과 관련된 것들을
하나도 쓸 수가 없습니다. (위 예제는 그래서 리눅스에서 테스트할 수 밖에 없었습니다;;)

그 외에 MPI 등의 “심각한” 분산 API들을 쓰던 프로그래머들은 이게 애들 장난이냐 하면서 없는 기능들을 지적할 수도 있는데, 아무래도 표준 라이브러리로써 아주 간단하고
기초적인 기능만 제공하는 것이 목적이고, 셋업이 복잡하거나 거대 프레임워크를 끌고 다니는 경우라면 표준에서 안정적으로 관리하기가 힘들겠죠. 그래서 multiprocessing을
도입하자 주장한 개발자는 이 모듈은 절대 다른 분산 관련 모듈을 쓰지 말라는 의미가 아니고
같이 쓰면 더욱 좋다고 강조합니다.

동영상(?)으로 보는 파이썬의 역사

Michael Ogawa의 code_swarm이라는
프로젝트에서 오픈소스 프로젝트의 CVS나 SVN 등 소스 저장고를 분석해서 일어난 작업들을
시각적으로 보여주는 걸 만들었습니다. 요새 UbiGraph같은
도구도 나오고 하는 걸 보면 시각화가 정말 굉장히 유행이네요~


code_swarm – Python from Michael Ogawa on Vimeo.

저는 3분 50초 쯤에 약간 왼쪽 아래에서 나타나서 잠시 머물다가 사라집니다;;; -ㅇ-;;;;;

이 영상은 미디어아트와 데이터 시각화에서 많은 관심을 모았던
Processing으로 만들었다고 하는데.. 전에 봤을 때는 괜히 어렵기만 하고 별 쓸모 없어보니더니
이걸 보니 확 땡기는군요. ^^;;

— via Python Daily URL

“내 이름 어때” 만든 이야기~

며칠 전에 올렸던 “내 이름 어때?”를 만들면서 썼던 여러 가지 기술적인 부분에 대해서
간단하게 정리해 봅니다. 물론 django로 만들었습니다! 이히히

Django 템플릿에서 한글 조사 처리

이름 뒤에 은/는 이/가 같은 것들을 제대로 붙이려면 아무래도 템플릿에서 처리를 해 줘야하는데,
django에서는 애플리케이션에서 직접 템플릿 태그나 필터를 정의하는 걸 매우 장려하는 분위기라서
“필터”를 따로 정의해서 처리했습니다.

템플릿에서 이렇게 쓰려고 하는 부분이 있다면:

필터 정의를 이렇게 해 줬습니다.

마지막 줄에서 1:로 굳이 잡아준 이유는 이름 뒤의 ~이 처럼 받침이 없으면 끝에 안 붙는 경우도
처리해 주려고요..

추세 해석

이름의 인기가 늘고 있는지 줄어드는지를 글자로 판단해서 표현해 주기 위해서, 간단한 계산식을
사용했습니다. 우선 원 데이터 자체는 샘플수가 적어서 노이즈가 많기 때문에 보통 많이 쓰이는
9개 윈도우 평균으로 했고, 이렇게 하면 18개 포인트가 나와서 세 부분으로 나눠서
앞 중간 뒤의 평균을 다시 구해서 3가지 값이 나왔습니다. 그래서 눈으로 딱 보면 값이 계속
증가하는지, 올라갔다 내려갔다 하는지를 볼 수 있는데요, 그냥 값으로 볼 수는 없으니
앞/중간 과 중간/뒤의 각각의 변동폭을 0에서 1사이로 정량화해서 봤습니다. 변동폭은 이름마다
절대량이 다르기 때문에 상대량으로 비교해야해서 아래와 같은 식으로 썼습니다.

\delta = {{\arctan {\log {N_B \over N_A}}} \over \pi} + 0.5

보기엔 약간 쓸데없이 복잡하긴 하지만, 그냥 상대비율을 (0, 1) 사이로 넣어주는 일 밖에 안 합니다;;;

이렇게 나온 값으로 앞 뒤가 모두 (0.4, 0.6) 구간에 들어오면 “꾸준한 추세입니다.”라고 하거나,
앞-중간은 (0.0, 0.3), 중간-뒤는 (0.0, 0.5) 구간에 들어가면 앞 반쪽에서 감소세가 강하고
뒷 반쪽에서 감소세가 둔하다는 의미이므로 “확 줄어들다가 잦아드는 추세입니다.”라고 보여주는 식으로
주된 패턴들을 “대충” 느낌으로 나열하는 방법으로 코딩했습니다. 크흐;

구글 차트

이름 전체의 성별 성향이나 이름의 시대적 경향, 이름 글자의 시대적 경향을 보이는 부분에서
구글 차트를 불러서 사용했습니다. 구글 차트는 직접 URL을 코딩하는 방법은 아니고,
pygooglechart를 사용했는데요,
이게 의외로 그런대로 잘 만들어서 웬만한 기능은 불편없이 쓸 수 있게 돼 있더군요. ?

다만, 하나 기술적인 문제가 있었던 부분은 이름 글자의 시대적 경향 같은 경우에는
글자마다 실수값 18개씩(경향)이 저장돼야 하기 때문에, 이걸 그냥 저장하는 건 여러모로
번거롭고 해서 구글 차트 API에서 쓰는 0~4095 사이 인코딩하는 방법으로 썼습니다.
(base64와 거의 같은 방법입니다.) 그래서, 저장은 바로 구글 차트 API URL에 쓰면 되는
형태가 돼서 다시 불러올 때 매우 빠르게 불러올 수 있긴 한데, 문제는 한 이름 안에
이름 앞자와 뒷자의 경향을 모두 보여줘야하기 때문에 둘의 그래프 크기를 제대로 조절해 주지
않으면 각 글자의 크기가 잘못 나온다는 점이었습니다.

그래서 결국 선택한 방법은 보여줄 때 앞자 뒷자 인코딩된 값을 다시 풀어서 큰 쪽의 스케일로
맞춘 다음에 다시 인코딩하는 -.,-; 약간 노가다성 방법을 썼습니다. 역시 이런 부분은
numpy의 array의 도움을 많이 받을 수 있었습니다.

확장코드 인코딩/디코딩 부분을 따로 떼서 쓸 일이 좀 있을 것 같아서..

통계치가 적은 이름의 성별 추정

역시 통계 샘플 크기가 작아서 주요 이름들을 빼고는 제대로 된 통계치를 낼 수 없어서
주요 이름들의 성별 경향으로 학습한 걸로 예측하는 부분이 필요했습니다.
이번에는 아예 사용된 적 없는 글자까지도 어떻게 좀 해 보려고
통계치에 전혀 의존하지 않고 그냥 자소별로 분해해서 이름만 피처로 사용하기로 했습니다.
그래서 보통 SVM
쓰는 것이 여러모로 대세이기는 하지만, 카테고리성(이산) 피처값에 매우 유리한
random forest을 썼습니다.
(물론 제가 수학을 워낙 못하는 것도 큰 요인으로;;;;)

Random forest는 아무래도 쓸 수 있는 구현이 적다는 게 큰 문제인데요.
파이썬에서 쓸 수 있는 orange를 쓰면 정말
좋겠지만, 아쉽게도 이 구현은 리그레션은 지원하지 않고요. Y.Y
R용 패키지인
party
randomForest
중에 선택해야하는데, party를 먼저 했으나 메모리 3기가를 먹더니 죽었고 (-_-)
randomForest는 안정적으로 대략 200메가 정도 먹고 그런대로 쓸 만한 결과를 줬습니다. ?

학습 기법 측면에서는 남자 샘플이 2배 정도 되기 때문에 편향 문제가 있어서 샘플링 조절을
좀 해야했는데요, 그냥 복잡한 것 쓰지 않고 대략 0.3 밑을 반 다운 샘플링하니까 전체적으로
분포가 윗쪽하고 아랫쪽이 그런대로 맞았습니다. 중성적인 이름이 수가 훨씬 적은 것도 또한
중성적 이름 쪽에서 오차를 많이 발생시킬 수 있는 요인이 될 수 있는데, 이쪽에서 오버샘플링을
하려고 하다가 “될 거 같으면 대충해도 돼야 하는거지” 하는 교수님 말씀이 귓가를 스치며
놀이인데 대충하자 하고 -ㅇ-;; 크흐; 그래서 결국 10-fold cross validation으로
평균 피어슨 연관성이 0.97 정도 나왔습니다. (만… 역시 사람 느낌하고 좀 다른
사례가 개별적으로는 제법 많이 발견되긴 하네요;)

페이지 내용 캐시

서비스를 공개한 다음 날 점심시간이 좀 지나고 나서는 접속이 폭주해서, 실시간 계산이 상당히
있었던 구현 특성상 앞으로 어떻게 될 지 참 고민이 있었는데요; 그래서 마침 전혀 필요없겠다
싶어서 꺼놨던 django의 캐시 프레임워크
살려서 해 봤습니다.
백엔드를 선택할 수 있는데, 역시 제일 잘 나가는 memcached를 썼습니다. 이거 소문대로 깔끔하고 잘 돌아가네요. ^_^;

Django는 다행히도 템플릿에서 일부만 특정 변수에 따라서 캐시하는 기능이 있어서
이름에 따라 바뀌는 부분, 성에 따라 바뀌는 부분을 따로 따로 캐시하도록 3조각으로
따로 캐시해서 생각보다 훨씬 간단하게 쉽게 캐시로 넣었고요, 지금은 CPU부하가 전보다
같은 요청에서 거의 1/10로 줄어들었습니다! 이히히.

다른 사소한 것들..

몇 분께서 물어보셨던 게 자료처리나 통계처리는 어떤 걸 썼느냐가 있는데, 특별히 쓴 것은 없구요, 파이썬 하나면 다 해결됩니다. -ㅇ-;
물론 numpy, matplotlib도 아주 큰 도움이 됐습니다.
collections.defaultdict를 전에는 그렇게 자주 쓰지는 않았는데, 이번에 좀 과격하게
3~4 단계 쑥쑥 defaultdict를 겹쳐서도 써 봤더니 pickle이 잘 안 되는 문제만 빼고는, 코드를 아주 많이 줄여준다는 점에서
아주 사랑스러웠습니다.

후속편으로는 이번에 들어온 로그를 한 번 분석해 보려고 하고 있습니다. ^^;Watch Full Movie Online Streaming Online and Download

이터레이터 팁 몇 가지

나중에 쓰려고 쌓아두고 있던 간단한 예시인데, 더 이상 쌓이지가 않아서 (–;)
방출해 봅니다;

파이썬 이터레이터/제너레이터는 함축적으로 프로그래밍하는 걸 즐기는 사람들에게는
정말 재미있지만, 절차적 프로그래밍을 하다가 갑자기 이터레이터를 쓰는 게 적응이
잘 안 되는 경우도 많이 볼 수 있습니다. 최고의(!) 파이썬 책으로
유명한 David Beazley가 지난 3월에 PyCon 2008에서 튜토리얼로
시스템 프로그래머를 위한 제너레이터 트릭을 발표했습니다. 여러모로 재미있는 내용인데요~ 저기서는 제너레이터를
주로 다뤘는데, 몇 가지 이터레이터와 관련된 사용 예를 소개해 드리려고요~
(별로 관련 없는 것이 뒤죽박죽;;)

zip을 쓰면 이터레이터를 일정 개수씩 빼오는 걸 간단하게 할 수 있습니다.

빈칸이 올 때까지 입력받은 걸 리스트로 받으려면?

딕셔너리 2개에서 양쪽 중 하나라도 키가 있는 것들을 뽑아서 돌려서 합치려는 경우..

(이 경우는 collections.defaultdict를 써도 간단합니다.)

리스트를 받아서 순위를 계산

(이건 뭐 주제하고 상관도 없고 제멋대로;;;)

파이썬 문법을 내 맘대로 python4ply

그동안 파이썬은
조건 표현
with절같이
문법을 바꿔달라는 수 많은 사용자들의 요청을 받아들여 문법을 추가한 사례가
여럿 있기는 했지만, switch-case나 for-from-to 같이 디자인 상의
일관성 문제로 인해서 받아들여지지 않은 문법도 많이 있었습니다.

요즘 계속 영역-특정적 언어(Domain-specific Language)에 대한 사용처가
늘고 있는데 파이썬을 특정 목적에 쓰자면 종종 대형 프로젝트에서는 문법을
고치는 게 득이 될 경우도 많이 생각할 수 있습니다.
그래서 전처리기를 사용해서 쓰는 방법도 있지만, python4ply는 이걸 좀 더
깔끔한 방법으로 처리하기 위해 등장했습니다.
나온지는 꽤 오래되었지만, 갈 수록 중요한 변환점을 찍은 모듈로
지속적으로 언급되고 있습니다.

원래 PLY는 파이썬에서 lex/yacc를
지원하기 위한 파서 제너레이터인데, python4ply는 PLY에서 파이썬을 파싱하고
그걸로 파이썬 바이트코드를 생성해서 직접 파이썬 코드 파싱/컴파일을 만들었기 때문에
그 부분을 직접 조절할 수 있도록 했습니다.

예를 들면 튜토리얼에서 예제로 들고 있는 것에서 이런 문법도 보여주고 있습니다.

파싱과 컴파일을 모두 건드리고 있으니 문법은 원한다면 얼마든지 바꿀 수 있는데,
python4ply는 소스 구조도 아주 깔끔하게 잘 정리되어 있는 편이라, DSL을 만들어야
하는 상황이라면 언제나 유용하게 쓸 수 있을 듯 합니다.

사실 python4ply가 나온 이후로 python-dev 메일링에 누군가 새로운 문법 뭔가 좀
넣어달라, 또는 파이썬 3에 2.x호환성 좀 넣어달라 요청만 올라오면 python4ply
URL을 누군가 덥썩 던져주고서는 그 다음부터는 무시하는 분위기가 됐지요. :>
누구나 어렵지 않게 할 수 있을 거라고 생각하고 있던거지만, 실제로 구현이 되고나니
영향을 꽤 많이 미치고 있는게 역시 가능하다고 생각만 하고 있는 것과 실제 구현체가
나온 것은 영향력이 차이가 좀 있군요.