팀과 만남: Brett Cannon

원문: Meet the Team: Brett Cannon (날짜: 2011-08-24, 작성자: Brian Curtin)

이 글은 "팀과 만남" 시리즈 중의 하나로, 파이썬 코어 개발팀을 간단히 소개합니다.

이름:	Brett Cannon
사는 곳:	미국 캘리포니아 샌프란시스코
홈페이지:	https://profiles.google.com/bcannon
블로그:	http://sayspy.blogspot.com

파이썬을 사용한 지는 얼마나 되었습니까?

2000년 가을부터 입니다.

코어 커미터가 된 지는 얼마나 되었습니까?

2003년 4월부터(PyCon 2003이 끝난 직후) 입니다.

코어 개발자로 출발은 어땠습니까? 처음 한 커밋을 기억하고 있습니까?

사람들에게 제 패치를 커밋해달라고 계속 귀찮게 한 덕분에 저는 코어 개발자가 될 수 있었습니다. (이 트릭은 예전만큼 잘 통하지는 않습니다. 파이썬이 2003/2004년에 폭발적인 인기를 얻기 전에만 가능했던 특혜입니다.) 저는 2002년 8월부터 Python-Dev Summaries(요약)를 다시 부활시키는 일을 하였는데 (이후 2년 반동안 계속하였습니다.) 요약을 정리하면서 수정이 필요한 잡다한 이슈를 꽤 자주 건드리곤 했습니다. 이미 python-dev 리스트에는 자주 참여했기 때문에 사람들에게 저의 패치를 확인하여 대신 커밋해달라고 부탁했었습니다. 어느 날 Guido가 왜 직접 커밋하지 않느냐고 물어오길래 저는 커밋 권한이 없다고 대답하였습니다. Guido는 바로 "이제 할 수 있을 거에요"라고 했습니다.

나의 첫 커밋(체인지셋 28686)은 time.strptime()에 문자열 이스케이프를 수정한 것으로 파이썬 자체에 대해 제가 처음으로 기여한 것입니다.

현재 파이썬의 어떤 부분을 작업하고 있습니까?

import 체계 쪽과 파이썬 언어가 모든 VM에서 잘 동작하도록 하는 쪽에 관심을 두고 있습니다.

코어 개발 작업을 하지 않을 때에는 파이썬으로 무엇을 하십니까?

제 박사 학위 논문의 서버 쪽 부분을 파이썬으로 구현하려고 했습니다. 그 밖에 개인적인 모든 프로젝트에 가능한 한 파이썬을 사용하려고 합니다. 앞으로 Google에서 할 일도 대부분 파이썬을 사용할 것입니다.

프로그래밍을 하지 않을 때에는 무엇을 하십니까?

저는 TV로 넘어온 엄선된 영화를 즐겨보는 매니아입니다. (2000년 여름에 무더위로 텔레비전을 잃어버린 것은 뜻하지 않게 제게 일어났던 일 중의 최고였습니다. 제 의지로 했던 일 중의 최고는 아내와 결혼한 것입니다.) 아니면 무엇인가 열심히 읽습니다. 대개 잡지나 웹 사이트이지만 책도 항상 읽는 중입니다.

팀과 만남: Michael Foord

원문: Meet the Team: Michael Foord (날짜: 2011-08-08, 작성자: Brian Curtin)

이 글은 "팀과 만남" 시리즈 중의 하나로, 파이썬 코어 개발팀을 간단히 소개합니다.

이름:	Michael Foord
사는 곳:	영국 노샘프턴
홈페이지:	http://www.voidspace.org.uk/

파이썬을 사용한 지는 얼마나 되었습니까?

처음에는 취미로 2002년부터 파이썬을 사용했습니다. 일로서는 2006년도에 파이썬을 사용하기 시작했습니다. 파이썬 프로그래밍의 시작은 Play By Email 게임에서 정보를 수집하는 프로그램을 작성하려는 사람들과 함께 한 것이 계기가 되었습니다. 우리 중 누구도 한동안은 프로그램을 작성하지 못하였고 그때 막 Smalltalk을 사용하기로 했었으나 누군가가 파이썬으로 해보자고 제안했습니다. 그 후로 저는 순식간에 파이썬에 빠져들었습니다.

코어 커미터가 된 지는 얼마나 되었습니까?

2009년 PyCon에서 코어 커미터가 되었습니다. 원래 IronPython에 관여했기 때문에 이루어진 것입니다.

코어 개발자로 출발은 어땠습니까? 처음 한 커밋을 기억하고 있습니까?

PyCon 2009 스프린트 동안 Gregory Smith와 또 다른 코어 개발자와 함께 Google이 unittest에 기여한 개선 사항을 통합하는 일을 하였습니다.

현재 파이썬의 어떤 부분을 작업하고 있습니까?

PyCon 스프린트에서 unittest에 대한 초기 작업을 한 후로 유지 보수 담당자가 따로 없었던 unittest에 대한 여러 문제점을 수정하고 개선하는 일을 하였습니다. 그 후 unittest의 유지 보수 담당자가 되었지만 표준 라이브러리의 다른 부분에도 기여하였습니다.

또한, Planet Python을 관리하는 것, PSF 회원이 되는 것, python.org webmaster 앨리어스에서 도움을 주는 것 등과 같은 여러 가지 방법으로 파이썬을 지원하고 있습니다.

코어 개발 작업을 하지 않을 때에는 파이썬으로 무엇을 하십니까?

본업으로는 Canonical에서 웹 개발을 합니다. Canonical 웹 사이트의 웹 서비스 기반 구조를 일부 작업하였고 Ubuntu와 통합되는 서비스도 몇 가지 작업했습니다. 정말 재미있는 일이었고 그들은 훌륭한 팀입니다.

여가 시간에는 unittest2 (unittest의 개선 사항을 다른 플랫폼으로 백포트), mock (목 객체를 제공하고 테스트에서 몽키 패치를 지원하는 테스팅 라이브러리)과 같은 프로젝트나 그 밖의 여러 조그만 프로젝트들을 작업합니다.

집필 작업도 더 하고 싶지만 지난 2년간 IronPython in Action 책을 쓰는데 헌신을 다한 관계로 당장은 이와 같은 큰 규모의 글쓰기 프로젝트를 또 할 것 같지는 않습니다.

프로그래밍을 하지 않을 때에는 무엇을 하십니까?

노샘프턴(영국)에 있는 교회에서 열심히 활동하고 있습니다. 상당한 시간을 쏟아 우리가 운영하는 자선 단체의 행정 업무를 돕고 있습니다. 이것은 Canonical에서 일하는 것이 좋은 이유 중의 하나입니다. 집에서 일할 수 있고, 여기에 뿌리를 내렸기 때문에 다른 곳으로 옮겨가지 않을 것입니다. (확실히 날씨 때문에 있는 것은 아닙니다.) 말할 필요도 없이 노샘프턴에는 파이썬 프로그래밍 일이 많지는 않습니다. 나의 첫 전업 프로그래밍 일은 편도로 두 시간 걸리는 통근을 하면서 런던에 있는 놀라운 팀과 함께 하였습니다. 4년간이나 그렇게 다니면서 그 일을 정말 즐겼었지만, 통근에서 해방된 관계로 다시 돌아가고 싶지는 않습니다.

XBox로 게임을 즐기기도 합니다. 불행히도 내가 좋아하는 게임이 있으면 몇 주동안 그 게임에 빠지기 때문에 조심해야만 합니다. 이러한 이유로 월드 오브 워크래프트, 이브 온라인 등을 하지 않았습니다. 또한, 매월 노샘프턴에서 긱(geek) 모임을 운영합니다. 파이썬 사용자 그룹에는 파이썬 사용자가 충분히 많지 않지만 모든 방면의 긱들을 모으면 꽤 됩니다. 보통 펍에서 모여 수다를 떨거나 자신의 최신 디지털 기기를 자랑합니다.

Windows용 파이썬 실행기

원문: A Python Launcher For Windows (날짜: 2011-07-11, 작성자: Paul Moore)

pywin32의 저자이자 오랫동안 Windows에서 파이썬 지원을 위해 노력해오신 Mark Hammond 님이 새로운 Windows용 파이썬 실행기를 주제로 한 PEP 397을 작성해 주셨습니다. 표준 라이브러리 logging 모듈의 저자인 Vinay Sanjip 님은 최근 이 실행기에 대한 구현을 작성해 주셨습니다. 구현은 https://bitbucket.org/vinay.sajip/pylauncher/downloads에서 다운로드 하실 수 있습니다.

새로운 실행기는 Windows에서 파이썬 스크립트(.py와 .pyw 파일)에 사용하려는 파이썬 버전을 지정할 수 있어서 파이썬 2와 3을 동시에 사용할 수 있도록 해줍니다.

Windows 사용자께서는 새 실행기를 다운로드하고 테스트해 주셔서 파이썬 개발자가 남은 문제를 해결하는데 도움을 주셨으면 합니다. 실행기는 독립 프로그램으로 패키징되어 있고 현재 나와있는 파이썬 버전들을 지원합니다. 실행기가 최종적으로 완성되면 파이썬 3.3에 포함될 것입니다. (독립 패키지도 이전 버전 파이썬 사용자를 위해 계속 제공됩니다.)

실행기는 두 가지 버전으로 제공됩니다. - launcher.msi는 실행기를 Program Files 디렉터리에 설치하고 launchsys.msi는 System32 디렉터리에 설치합니다. (64비트 Windows용으로 64비트 버전도 제공됩니다.)

실행기에 대한 자세한 설명

실행기 동작에 대한 전체 명세는 PEP 397에 있습니다. 기본 원리를 요약하자면:

• 실행기는 두 가지 실행 파일을 제공합니다. - py.exe(콘솔 버전)과 pyw.exe(GUI 버전)
• 실행기는 .py(콘솔)과 .pyw(GUI) 파일 확장자에 대한 핸들러로 등록됩니다.
• 스크립트가 실행되면 실행기는 스크립트에서 Unix 스타일의 #!(쉬뱅) 행을 찾아봅니다. 실행 파일 이름으로 python (시스템 기본 파이썬), python2 (기본 파이썬 2 릴리스), python3 (기본 파이썬 3 릴리스)을 인식합니다. 이것은 사용자 별, 컴퓨터 별로 자세히 설정할 수 있습니다.
• py.exe 명령이 독립적으로 실행될 때에는 파이썬 대화식 인터프리터를 실행시킵니다. 명령 행 스위치가 지원되어서 py -2는 파이썬 2를, py -3은 파이썬 3을, py는 기본 버전을 실행합니다.

간단 사용 설명서

실행기는 설치가 되면 자신을 .py와 .pyw 스크립트에 연결시킵니다. 다른 조작을 하지 않았다면 스크립트는 컴퓨터에 설치된 기본 파이썬을 사용하여 실행될 것입니다. 그러므로 전과 차이는 없을 것입니다. 콘솔을 자주 사용한다면 .py를 PATHEXT 변수에 추가해서 스크립트가 별도의 콘솔에서 실행되지 않도록 하면 좋습니다.

파이썬 2를 사용해야 하는 스크립트에는 첫 행에 다음을 추가합니다.

#!/usr/bin/env python2

(이는 Unix와 호환되는 형식입니다. Unix 호환성이 필요 없다면 #!python2라고 해도 됩니다.)

반대로 파이썬 3을 사용해야 하는 스크립트에는:

#!/usr/bin/env python3

을 첫 행에 추가합니다.

파이썬 인터프리터를 다음과 같은 명령을 통하여 시작할 수 있습니다.:

# 기본 파이썬 버전
py
# 파이썬 2
py -2
# 파이썬 3
py -3

위와 같이 사용하려면 py.exe 실행 파일이 실행 경로 상에 있어야 하는데 launchsys 버전의 설치 프로그램을 사용했다면 자동으로 됩니다. launcher.msi 버전은 설치 디렉터리 (C:\Program Files\Python Launcher)를 수동으로 PATH에 추가해야 합니다.

더 읽을거리

다음 python-dev 메일 스레드들은 핵심 논의 사항을 다룹니다:

• PEP 초안에 대한 Mark의 첫 공지: http://mail.python.org/pipermail/python-dev/2011-March/109509.html
• PEP 두 번째 초고: http://mail.python.org/pipermail/python-dev/2011-March/109786.html
• 실행기의 C 구현에 대한 Vinay의 첫 질의: http://mail.python.org/pipermail/python-dev/2011-June/112145.html
• Vinay의 C 구현에 대한 공지: http://mail.python.org/pipermail/python-dev/2011-July/112184.html
• Vinay의 테스트 요청: http://mail.python.org/pipermail/python-dev/2011-July/112251.html

3.2.1 릴리스 후보 2가 나왔습니다

원문: 3.2.1 Release Candidate 2 Released (날짜: 2011-07-06, 작성자: Brian Curtin)

6월의 릴리스에 이어 3.2.1의 두 번째 릴리스 후보가 지금 막 나왔습니다. 5월 15일에 있었던 첫 번째 릴리스 후보 이후로 40가지가 넘는 문제를 고쳐졌습니다. 여러분 모두 3.2.1 최종 릴리스 전의 마지막 모습을 확인하신다는 차원에서 각자의 프로젝트에 이 릴리스 후보를 테스트해 보시기를 바랍니다.

무엇이 고쳐졌을까?

I/O

#1195는 고쳐지지 않은 채로 몇 년이 지났습니다. 그러나 fgets을 호출하기 전에 오류 상태를 초기화하는 간단한 수정만으로 input() 내에서 CTRL-D가 sys.stdin.read()를 중단시키는 문제를 해결하였습니다. io 시스템은 #12175에서 read()가 None을 반환하면 readall() 메소드도 None을 반환하도록 하였고, 파일을 열지 못할 때에는 ValueError를 발생하도록 했습니다.

RC2에서 등장한 것은 아니지만 3.2.1의 중요한 수정 사항인 #11272는 Windows에서 input()의 끝에 붙어 오는 \r 문제를 고친 것입니다. 이 문제는 수차례 보고된 바 있고 여러 사람이 겪고 있는 문제이므로(distutils의 upload 명령 등?) 3.2.1이 해결책이 될 수 있기를 희망합니다.

Windows

3.2.0은 Windows에 os.symlinks 지원이라는 새 기능을 추가하였는데 덕분에 #12084가 문제가 되었습니다. os.stat가 Windows 심볼릭 링크를 잘못 계산하고 있었던 것으로 밝혀져 stat 함수의 여러 가지 내부 동작을 수정했었습니다.

한 사용자가 os.path.isdir이 느리다는 것을 밝혀냈는데, 그 원인은 os.stat로 특히 심볼릭 링크를 계산할 때가 문제가 됩니다. (일반적으로 보통 파일보다 두 배는 느려짐) 누구에게도 os.path.isdir이 성능상의 병목이 되지는 않지만, 인터프리터가 시작될 때 여러 차례 호출되므로 #11583에서 GetFileAttributes를 사용하도록 하여 기동 시 속도를 조금 높였습니다.

subprocess

Popen 객체를 생성할 때 올바르지 않은 인자를 넘기면 AttributeError가 발생했습니다. 이것은 #12085로 보고되었고 보고한 사람이 고쳐주었습니다. 3.2.0에서 변경된 것 때문에 Popen에서 환경 변수가 비어있을 때, 특히 env 인자를 제대로 처리하지 못하였습니다. 이 문제는 #12383으로 올라와 바로 고쳐졌습니다.

...그 밖에!

3.2.1 RC2의 전체 변경 사항을 보려면 변경 로그를 확인하시고 지금 바로 다운로드 해보십시오!

늘 그렇듯이 문제를 발견하시면 http://bugs.python.org로 알려주세요. 고품질의 파이썬 릴리스를 제작할 수 있도록 도움을 주셔서 고맙습니다.

6월의 릴리스 - 2.6.7, 2.7.2, 3.1.4

원문: June Releases - 2.6.7, 2.7.2, 3.1.4 (날짜: 2011-06-14, 작성자: Brian Curtin)

현재 유효한 브랜치 모두에서 업데이트가 나온 6월은 파이썬 릴리스에 있어서 큰 의미가 있는 달입니다.

2.6.7

새로 릴리스된 파이썬 2.6.7은 소스 코드만 제공되며 보안 문제 세 가지를 고쳤습니다. 이제 2.6 계열은 보안 모드에 있기 때문에 2013년 10월까지 소스 코드 형태로만 필요에 따라 릴리스될 것입니다. 바이너리 설치가 필요하면 2.7이나 3.2로 업그레이드 하시길 바랍니다.

2.6.7은 앞서 urllib 취약점에서 다루었던 수정 사항이 반영된 첫 릴리스입니다. 거기에 추가로 smtpd DoS 취약점(이슈 #9129)과 SimpleHTTPServer.list_directory XSS 취약점(이슈 #11442)도 고쳤습니다.

2.7.2

2.x 대의 최종 마이너 버전인 2.7은 2010년 11월에 2.7.1이 릴리스된 후로 150개가 넘는 버그 수정이 이루어졌습니다. 2.7.2는 2.6.7에서 언급한 보안 문제 수정을 모두 포함하고 있으며, 소스 및 바이너리 설치 프로그램은 6월 12일부터 사용하실 수 있습니다.

여러 가지 죽는(crash) 문제가 고쳐졌습니다. 여기에는 파이썬이 파이썬 밖에서 관리하는 메모리를 다른 스레드가 수정하는 동안 부적절하게 사용하는 상황, 클래스에서 __abstractmethods__를 삭제하는 경우, 메모리 맵(memory-mapped) 파일을 그 크기를 넘어서 접근할 때 등이 있습니다.

getpass에서는 CTRL-C 및 CTRL-Z 처리에 일어난 퇴보를 바로 잡았습니다. multiprocessing에는 Windows 서비스를 동결된(frozen) 실행 파일과 같이 처리한 것과 multiprocessing.Pool의 워커(worker)를 종료할 때의 경쟁 조건을 바로 잡은 것을 포함하여 여러 가지 수정이 있었습니다. mmap은 32비트 빌드에서도 4 GB 이상의 파일 크기와 오프셋에 작동하도록 수정되었고 쓰기 불가능한 맵(map)에 쓰기를 시도할 경우 세그폴트를 내지 않고 TypeError를 발생하도록 하였습니다.

전체 변경 사항은 2.7.2 새 소식 파일을 참고하세요.

3.1.4

3.1.4는 3.1.x 대의 최종 버그 수정 릴리스로 3.2 대로 옮겨감에 따라 3.1은 보안 모드에 접어듭니다. 3.1.4는 2010년 11월에 3.1.3이 릴리스된 이후의 100개가 넘는 버그 수정을 포함하고 있습니다. 2.7.2와 마찬가지로 6월 12일부터 바이너리 설치 프로그램을 사용할 수 있으며, 3.1.4는 2.6.7에서 언급한 보안 문제의 해결을 포함하는 첫 번째 3.x 릴리스입니다.

3.1.4는 객체에서 __dir__을 조회할 때 문제, os.stat 및 os.utime의 Windows 구현에서 2038년 이후 날짜 문제, 64비트 지원을 위한 여러 가지 문제들을 수정하였습니다. io 라이브러리는 읽은 것이 없을 때 None을 반환하고 다른 곳에서는 적절한 예외를 반환하도록 여러 군데가 변경되었습니다. 64비트 Windows에서 ctypes의 콜백(callback) 인자가 고쳐졌고 죽는 문제도 해결되었습니다.

전체 변경 사항은 3.1.4 새 소식 파일을 참고하세요.

3.2.1

3.2.1은 현재 릴리스 후보 단계에 있습니다. 첫 번째 릴리스 후보는 이미 완결되었고 두 번째가 곧 나올 예정입니다. 3.2 사용자분들은 릴리스 후보를 사용해 보시고 문제가 있는지 확인해 주시면 정말 고맙겠습니다. 보고할 버그가 있다면 bugs.python.org에 제출해 주시기 바랍니다.

파이썬 3.3에 새로 추가된 faulthandler 모듈은 디버깅을 도와줍니다

원문: New faulthandler module in Python 3.3 helps debugging (날짜: 2011-05-12, 작성자: Victor Stinner)

여러분의 프로그램 사용자가 프로그램이 죽거나 멈춘다고 보고해 온다면 여러분이 할 수 있는 일은 그 사용자가 더 많은 정보를 모을 수 있도록 하거나 그 상황을 재현할 수 있는 시나리오를 만들어 내도록 돕는 것 뿐입니다. 사용자의 확실한 시나리오라 할지라도 환경이 서로 달라서(예를 들자면 운영 체제나 컴파일러) 개발자가 그 상황을 재현하지 못하기도 합니다. 운이 좋은 경우는 사용자가 디버깅 도구를 설치하기도 하지만, 대부분은 같은 상황에 대해 다른 누군가가 더 많은 정보를 얻어줄 때까지 기다려야만 할 것입니다.

심각한 오류

파이썬 3.3에서 새로 추가된 faulthandler 모듈이 이런 문제에 도움이 됩니다. faulthandler는 세그멘테이션 폴트, 0으로 나눔, 어보트(abort), 버스 오류와 같은 심각한 오류 상황에서 파이썬 트레이스백(traceback)을 기록해주는 기능을 제공합니다. 이 기능은 프로그램에서 faulthandler.enable()를 사용하거나 파이썬 실행 파일에 -X faulthandler 옵션을 주거나 환경 변수를 PYTHONFAULTHANDLER=1로 설정하여 활성화할 수 있습니다. 출력의 예:

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

타임아웃

faulthandler는 또한 faulthandler.dump_tracebacks_later(timeout)를 사용하면 주어진 타임아웃 후에 트레이스백을 기록해줍니다. 이 함수를 다시 호출하면 타이머는 재시작되며, faulthandler.cancel_dump_tracebacks_later()를 호출하면 타이머는 중단됩니다. 출력의 예:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

repeat=True 옵션을 사용하면 매 timeout 초마다 기록해줍니다. exit=True를 사용하면 안전하지 않은 방식으로(예를 들면 파일을 플러시하지 않음) 바로 프로그램을 종료시킵니다.

사용자 시그널

프로그램이 실행 중인 호스트에 접근할 수 있다면 faulthandler.register(signal)를 사용하여 signal을 받았을 때 트레이스백을 기록하도록 시그널 핸들러를 설치해 둘 수 있습니다. 예를 들면, UNIX에서는 SIGUSR1 시그널을 활용할 수 있습니다. kill -USR1 <pid>로 현재 트레이스백을 기록할 수 있을 것입니다. 이 기능은 Windows에서는 사용할 수 없습니다. 출력의 예:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

다른 사용법으로 프로그램에서 직접 faulthandler.dump_traceback()를 호출하는 것도 가능합니다.

보안 문제와 출력 파일

보안상의 이유로 기본적으로 faulthandler는 비활성화 되어 있습니다. 주된 이유는 sys.stderr의 파일 디스크립터를 저장했다가 그 파일 디스크립터로 트레이스백을 기록하기 때문입니다. 만약 sys.stderr가 닫힌 후 그 파일 디스크립터가 재사용 된다면 그 파일 디스크립터는 소켓, 파이프, 중요한 파일, 또는 다른 어떤 것이 될 수 있습니다. 기본적으로 faulthandler는 트레이스백을 sys.stderr에 기록하지만 다른 파일을 지정할 수 있습니다. 자세한 내용은 faulthandler 문서를 참고하시기 바랍니다.

예전 파이썬 버전을 위한 외부 모듈

faulthandler는 파이썬 2.5에서 3.2를 위해 PyPI에 외부 모듈로도 유지 보수되고 있습니다. 파이썬 3.3의 모듈과 이 외부 모듈의 가장 큰 차이는 dump_tracebacks_later()의 구현에 있습니다. 파이썬 3.3은 잠금에 타임아웃을 주어 쓰레드를 사용하는 반면 외부 모듈은 SIGALRM과 alarm()을 사용합니다.

잠금 타임아웃은 파이썬 3.3의 새로운 기능으로 마이크로초 단위의 정밀도를 갖습니다. 예전 버전에서 사용되는 alarm() 타이머는 1초의 정밀도를 갖으며 SIGALRM 시그널은 실행 중인 시스템 호출을 EINTR 오류를 내면서 실패하도록 하여 중단시킬 수 있습니다.

초기 성공 사례

새로 추가된 faulthandler 모듈은 이미 우리의 빌드봇(buildbot)에서 경쟁 조건을 추적하는데 도움을 주었습니다. 이 모듈이 여러분의 프로그램에서도 도움이 되기를 희망합니다.

포르투갈어, 독일어, 한국어, 중국어 번체 번역본

원문: Portuguese, German, Korean, and Traditional Chinese Translations (날짜: 2011-05-19, 작성자: Michael Markert)

파이썬 인사이더 번역 프로젝트가 나날이 자라고 있습니다! 오늘부로 이 블로그의 포르투갈어, 독일어, 한국어, 중국어 번체 버전을 시작합니다. 번역가들이 이미 지난 글들을 올리기 시작했습니다. 다른 번역본과 마찬가지로 이들 번역판은 파이썬 인사이더(영문)의 원래 글보다는 조금 늦게 올라올 것입니다.

루마니아어, 중국어 간체 번역본

원문: Romanian and Simplified Chinese Translations (날짜: 2011-05-09, 작성자: Doug Hellmann)

파이썬 인사이더 팀은 오늘 블로그 둘을 새로 소개하게 되어 매우 기쁩니다. 번역 프로젝트에 루마니아어와 중국어 간체 번역가가 참가하여 이미 지난 글들을 올리기 시작했습니다. 다른 번역본과 마찬가지로 이들 번역판은 파이썬 인사이더(영문)의 원래 글보다는 조금 늦게 올라올 것입니다.

Jython이 Mercurial로 옮겨 갑니다

원문: Jython Migrates to Mercurial (날짜: 2011-05-07, 작성자: Philip Jenvey)

Jython이 마침내 Subversion에서 Mercurial으로 이전을 마쳤습니다. 여기에 오기까지 오랜 시간이 걸렸습니다. 유감스럽게도 Subversion 저장소를 다른 버전 관리 시스템으로 깔끔하게 변환하는 것에는 어려움이 많았습니다.

Jython의 새로운 공식 저장소는

http://hg.python.org/jython

입니다. 간편하게 포킹(forking)할 수 있게 BitBucket 미러도 제공됩니다.

더 큰 규모이지만 읽기 전용인 저장소인 http://hg.python.org/jython-fullhistory에는 현재 진행 중인 기능에 대한 브랜치(Mercurial 북마크로 변환됨)가 제공됩니다.

Mercurial 덕분에 Jython에 기여하는 것이 훨씬 쉬워졌습니다. 여러분도 포크(fork)를 하나 풀(pull)하셔서 Jython 2.6 개발을 도와주십시오!

파이썬 3.3은 OS/2, Windows 2000, VMS 지원을 중단합니다

원문: Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS (날짜: 2011-05-04, 작성자: Brian Curtin)

사용자의 수요에 맞추어 지원할 운영 체제 목록을 정리해야 하는 시간이 종종 다가옵니다. 릴리스의 품질을 유지하기 위해서는 개발 작업을 끝마쳐 줄 사람이 필요하기 때문에, 한 플랫폼에 기여하는 개발자의 수가 무엇보다 중요합니다. 다른 요인으로는 운영 체제가 얼마나 오래됐는지와 그것이 앞으로의 개발 작업에 얼마나 방해가 될 것인지도 중요합니다.

Victor Stinner는 OS/2 지원에 대한 질문을 한 지 1년 만에 CPython에서 OS/2와 VMS 지원을 중단할 것을 최근 제안하였습니다. Victor의 원래 질문은 유니코드 지원을 위해 끝이 없어 보이는 작업을 하는 도중에 나온 것이었습니다. 구체적으로 말하자면 os.execvpe()이 환경 변수를 PEP 383의 surrogateescape 핸들러를 통해 지원하는 것에 대한 문제였습니다. OS/2와 VMS는 현재 개발팀에서 대표자가 없어 릴리스 과정에서도 테스트를 하고 있지 않습니다.

이 글을 쓰는 중에 Windows 2000을 제거하는 것에 관한 잊혀진 예전 논의를 떠올리게 되었습니다. 그 당시에는 COMSPEC을 command.com으로 설정하는 시스템 또한 중대한 위기에 있었습니다. 이제는 그들 모두 OS/2, VMS와 함께 하게 되었습니다. 구식 API를 고려할 필요가 없도록 하면 개발 작업이 더 용이해지기 때문에 2010년에 수명을 다한 운영 체제인 Windows 2000은 제거되어야 합니다.

이들 운영 체제에 대한 지원을 중단하기 위해서 Victor와 나는 PEP 11을 갱신하기 시작하였습니다.

PEP 11

이 PEP는 더 이상 지원하지 않는 운영 체제의 목록을 보여주고, 그 목록에 운영 체제를 추가하는 절차를 설명합니다.

운영 체제 제거 절차를 시작하기로 결정하였다면 우선 공식적으로 지원하지 않는 것으로 발표합니다. 전통적으로 이런 발표는 개발 중인 버전에 적용되므로, OS/2, Windows 2000, VMS의 지원 중단은 파이썬 3.3에서 시작됩니다.

첫 단계는 아예 손을 떼는 것으로 백기를 드는 것입니다. 그것은 코드를 유지 보수하는 사람이 아무도 없고 릴리스의 품질을 보장하지 않는다는 신호입니다. 플랫폼의 사용자에게 해당 플랫폼이 지원되지을 것이라고 경고를 해주기 위해서 컴파일 및 설치 과정에 변경이 있을 것입니다. 새 소식 문서에는 새롭게 지원되지 않게 된 플랫폼이 나열될 것입니다.

한 번의 릴리스 사이클이 지나면 그 이후 버전부터는 당당하게 코드를 삭제할 수 있게 됩니다. 이번 경우 코드는 3.4에서 제거될 수 있습니다. 개발자는 코드를 한번에 다 제거하지는 않을 것이고 다른 일상적인 작업 도중 #ifdef 블록이나 configure 섹션, 오래된 코드를 만나게 되면 그들을 제거할 것입니다.

여러분이 할 수 있는 일

만약 여러분이 OS/2나 VMS 사용자이고 그들 플랫폼이 계속 지원되기를 바란다면 할 수 있는 일은 다음과 같습니다.

유지 보수 담당이 되기

활발히 활동하는 개발자보다 더 좋은 지원은 없습니다. 한동안 OS/2의 유지 보수를 담당했던 Andrew MacIntyre은 Victor의 첫 번째 OS/2 질문 도중에서 OS/2가 유니 코드 지원이 늦어지고 있기 때문에 이는 분명히 관심이 필요한 분야라고 했습니다. VMS는 http://www.vmspython.org를 통해서 외부에서 어느 정도 지원을 받고 있는 것으로 보이지만 이슈 11918에서 논의된 바와 같이 상류(upstream)에 계속하여 VMS를 지원하기 위해서는 누군가가 나서야 합니다.

해당 플랫폼을 맡아 보고 싶다면 개발자 가이드에서 현재의 개발 절차를 참고하십시오.

빌드 슬레이브 기증

활발히 활동하는 개발자가 있으면 그 플랫폼이 살아남을 가능성은 높아집니다. 빌드 슬레이브(build slave)가 있으면 살아남는 것은 물론이고 품질까지 좋아질 가능성이 높아집니다.

파이썬은 지속적인 통합에 Buildbot을 사용하는데 빌드 슬레이브로는 현재 Linux, Mac, Windows, Open Indiana (Solaris)의 여러 버전, 아키텍쳐, 시스템 구성이 제공됩니다. OS/2나 VMS를 위한 빌드 장비를 기증할 수 있다면 이들 플랫폼이 더 주류인 플랫폼들과 동등한 관심을 받을 수 있을 것입니다.

만약 OS/2나 VMS가 살아남을 수 있도록 시간이나 하드웨어를 기부할 수 있다면 python-dev 메일링 리스트에 문의하여 조율하시기 바랍니다.

파이썬 인사이더 번역 프로젝트

원문: Python Insider Translation Project (날짜: 2011-05-02, 작성자: David Menéndez Hurtado)

이 블로그의 콘텐츠는 파이썬 커뮤니티 전체에 유용하리라 생각되므로 저희가 우선적으로 해야 할은 가능한 많은 사람이 읽을 수 있도록 하는 것입니다. 독자를 늘리기 위해 이 블로그와 나란히 운영될 번역판을 제작할 번역가 팀을 구성하였습니다. 오늘부터 일본어와 에스파냐어 번역을 시작합니다.

번역본은 파이썬 인사이더(영문)의 글보다 조금 늦게 올라올 것입니다만 가능한 최신으로 유지하기 위해 노력하겠습니다.

사람 구함

번역팀은 아직 매우 소규모라 더 참여하실 분을 찾고 있습니다. 기존 언어에 작업을 하실 수 있는 분이나 다른 언어로 번역을 더 확장하실 분 모두 필요합니다. 어떤 쪽이든 도움을 주실 수 있으시면, Doug Hellmann (doug 쩜 hellmann 골뱅이 gmail)에게 연락 주시기 바랍니다.

팀과 만남: Brian Curtin

원문: Meet the Team: Brian Curtin (날짜: 2011-04-28, 작성자: Brian Curtin)

이 글은 "팀과 만남" 시리즈 중의 하나로, 파이썬 코어 개발팀을 간단히 소개합니다.

이름:	Brian Curtin
사는 곳:	일리노이주 시카고
홈페이지:	http://blog.briancurtin.com/

파이썬을 사용한 지는 얼마나 되었습니까?

일상적으로는 사용한 지는 6년이 되어 갑니다. 그전에는 대학 수업에서, 그리고 여름 인턴십에서 사용한 적이 있습니다.

코어 커미터가 된 지는 얼마나 되었습니까?

막 1년이 넘었습니다. 3월 24일이 개발자 그룹에 들어온 지 1년째입니다.

코어 개발자로 출발은 어땠습니까? 처음 한 커밋을 기억하고 있습니까?

업무로 익스텐션 모듈을 작성하다가 문서에 오류가 있다는 것을 발견하게 되어 간단한 패치를 보냈는데 Georg Brandl이 거의 바로 커밋을 하였습니다. 그렇게 금방 반영되어 최신 소스를 체크아웃하게 되었는데 그 후로 내가 사용하고 있는 모듈에 뛰어들어 더 알고 싶어졌습니다. 결국은 zipfile에 컨텍스트 매니저 지원을 추가하는 패치를 작성하게 되었습니다.

처음 몇 번의 커밋은 간단히 할 수 있는 일로 문서의 오류를 수정하였습니다. 첫 번째 코드 커밋은 winreg 모듈에 기능을 조금 추가하고 테스트 커버리지를 늘린 것이었습니다.

현재 파이썬의 어떤 부분을 작업하고 있습니까?

CPython 개발에 관여하는 사람 중에서 몇 안 되는 Windows 사용자로서 Windows 사용자가 겪는 모든 문제에 관심을 두고 있습니다. 그 때문에 내가 사용하지 않는 모듈을 포함하여 수많은 표준 라이브러리에 작업할 기회가 있었습니다. 인터프리터 자체에는 많은 일을 못 했지만, 앞으로 해볼까 합니다.

코어 개발 작업을 하지 않을 때에는 파이썬으로 무엇을 하십니까?

C++로 작성된 상거래 데이터베이스를 위한 여러 가지 테스트 도구를 만듭니다. 데이터 API에 대한 익스텐션 모듈이 있어서 회귀 테스트나 성능 테스트를 쉽게 작성할 수 있구요, 항상 다른 것도 더 만들어 보려고 노력 중입니다.

프로그래밍을 하지 않을 때에는 무엇을 하십니까?

야구의 열광적인 팬입니다. 봄에는 대학 야구, 여름에는 여러 리그에서 심판을 보고요, 시카고 커브스 경기들을 시청하거나 직접 가서 보기도 합니다.

팀과 만남: Nick Coghlan

원문: Meet the Team: Nick Coghlan (날짜: 2011-04-21, 작성자: Nick Coghlan)

이 글은 "팀과 만남" 시리즈 중의 하나로, 파이썬 코어 개발팀을 간단히 소개합니다.

이름:	Nick Coghlan
사는 곳:	오스트레일리아 브리즈번
홈페이지:	http://www.boredomandlaziness.org

파이썬을 사용한 지는 얼마나 되었습니까?

1999년경 네트워크 수업에서 강사가 파이썬을 사용했을 때 처음 접했는데요, 버전은 1.5.2였습니다. 2002년경 2.2를 자동화된 테스팅에 업무적으로 사용하기 시작한 후로 계속 써 왔습니다.

코어 커미터가 된 지는 얼마나 되었습니까?

Guido가 2005년에 PEP 343을 갱신하라고(주로 컨텍스트 메소드를 제거) 권한을 주었습니다.

코어 개발자로 출발은 어땠습니까? 처음 한 커밋을 기억하고 있습니까?

패치로 공헌한 것에 대해 말하자면, 2004년에 세 달간 휴가가 있어서 Raymond, Facundo와 함께 decimal 모듈을 작업했습니다. 주로 telco 벤치마크를 실행하면서 코드의 속도를 높힐 방법을 찾아냈습니다. decimal 모듈에서 사용된 이상한 꼼수(특수 값을 확인할 때의 빠른 경로나 숫자 튜플을 정수로 변환할 때 문자열을 사용하는 것 같은) 중 몇 가지는 그때 생긴 것입니다.

사실상 나의 첫 커밋은 PEP 343이라 할 수 있습니다. 그 다음은 아마도 2.5에 포함되면서 종료되었던 AST 컴파일러 브랜치일 것입니다.

현재 파이썬의 어떤 부분을 작업하고 있습니까?

나의 받은 편지함에는 주로 runpy, functools, contextlib와 관련한 것들이 들어 있습니다. Brett와 Victor가 작업하는 import나, Raymond가 작업하는 collections, itertools, 그 밖에 컴파일러에 일어나는 일들에도 관심을 두고 있습니다. 또한, 파이썬의 문화적인 측면에도 매료되어 있습니다.

코어 개발 작업을 하지 않을 때에는 파이썬으로 무엇을 하십니까?

사실 대단한 것은 없습니다. 업무에서 파이썬 관련한 것은 일반적으로 그 할 일만 하면 되는 것들이므로 해킹에 대한 요구는 별로 없습니다. 저의 디지털 음악 라이브러리를 정리할 무엇인가를 만들고 싶지만 그런 스크립트는 바로 지금이라도 금방 할 수 있는 작업입니다.

프로그래밍을 하지 않을 때에는 무엇을 하십니까?

태권도, 컴퓨터 게임, 축구, 독서 등등

새로운 블로그 디자인

원문: New Blog Design (날짜: 2011-04-19, 작성자: Doug Hellmann)

파이썬 인사이더를 피드 리더로 읽고 계신다면 Marcin Wojtczuk 님이 만들어주신 새로운 블로그 디자인을 보지 못하셨을 것입니다. 가벼운 느낌을 유지하면서도 멋지게 보여서 이 결과물이 더없이 만족스럽습니다.

Marcin 님, 수고해주셔서 감사합니다!

urllib/urllib2의 보안 취약점이 고쳐졌습니다

원문: urllib/urllib2 Security Vulnerability Fixed (날짜: 2011-04-14, 작성자: Brian Curtin)

Guido van Rossum은 파이썬 URL 라이브러리의 보안 문제인 CVE-2011-1521을 고친 것을 최근에 푸시했습니다. 보안 문제는 드물긴 하지만, 문제가 발생했을 때 문제를 보고하고 처리하고 고치는 과정은 커뮤티니가 참여할 수 있는 좋은 기회입니다.

문제 보고

만약 CPython의 보안 문제를 발견하시면, 일단 그 문제의 세부 사항은 비밀로 유지해 주시기를 부탁합니다. 정당한 보안 문제를 발견하였다면 그 내용을 코어 개발자에게 전달해야 하는데 가장 중요한 것은 간결하면서도 상세한 보고서를 작성하는 것입니다.

해당 문제로 시스템의 관련된 부분이 어떻게 영향을 받는지를 명확하게 설명하는 보고서가 좋은 보고서입니다. 문제가 특정 플랫폼이나 의존성 때문에 발생한다면 그것도 알 수 있으면 도움이 될 것입니다. 영향을 받는 버전도 알면 유용할 것이고, 현재 널리 사용되는 모든 버전에 대해 테스트를 해야 할 것입니다. 마지막으로, 문제를 보여주는 테스트 케이스가 있다면 꼭 포함해 주세요. 보고서는 security@python.org 그룹으로 보내야 합니다.

최근에 Google 보안팀의 Niels Heinen은 훌륭한 보고서를 제출해 주었습니다. 그는 표준 라이브러리인 urllib와 urllib2 모듈에서 HTTP 302 재지정(redirection) 처리에 관한 문제를 발견하였습니다. 그가 발견한 문제는 서버가 올바르지 않은 스킴(scheme)에 대한 요청을 재지정할 수 있기 때문에 데이터나 시스템이 위협받는 상황이 생길 수 있다는 것입니다. Neils의 처음 보고서에서는 재지정이 문제를 일으킬 수 있는 시나리오를 두 가지 설명했습니다.

첫 번째로 urllib/urllib2가 file:// URL 스킴에 대한 처리를 제공하기 때문에 file:///etc/passwd로의 재지정으로 패스워드 데이터가 노출될 수 있습니다. 또한, file:///dev/zero와 같은 시스템 장치로의 재지정은 서비스 거부(denial of service)를 일으키는 자원의 고갈 상황을 만들어낼 수 있습니다.

보고서 처리

보안 보고서는 민감한 내용을 담기 때문에 security@python.org 리스트는 보고서를 최대한 빨리 분석하여 조치를 취하는 소수의 믿을 수 있는 개발자 그룹이 담당하고 있습니다. 리스트에 전송할 내용을 암호화하고자 한다면 보안 소식 페이지에서 OpenPGP에 관한 내용을 참고하시기 바랍니다.

보고된 내용을 그룹에서 실제로 보안 문제라고 확정하게 되면 패치와 함께 공개적으로 버그 보고를 하게 됩니다. 이번 경우는 Guido van Rossum이 첫 패치와 함께 이슈 #11662로 공개하였습니다.

문제 고치기

Guido의 패치는 재지정을 http://, https://, ftp:// URL 스킴으로 한정하는 것입니다. FTP 재지정은 실제로도 흔히 사용되는 재지정으로 허용할 만한 것입니다. 예를 들면, 미러 시스템에서 다운로드를 받을 때 종종 지리적으로 가까운 FTP 서버로 요청을 재지정하는 때가 있습니다.

파이썬 2.x에서는 이제 FancyURLopener의 redirect_internal 메소드가 올바르지 않은 스킴으로 재지정하는 요청을 받으면 IOError를 발생시킵니다. HTTPRedirectHandler의 http_error_302도 같은 일을 하는데 이 경우 HTTPError를 발생시킵니다. 파이썬 3에서는 urllib.request를 똑같이 고쳤습니다. 패치와 함께 포함된 테스트 둘에서는 각각 올바른 스킴과 올바르지 않은 스킴으로 재지정을 시험해봅니다.

사용자가 이번 수정 사항을 받아 보려면, Python 2.5는 곧 나올 예정인 최종 보안 릴리스를 사용하면 됩니다. 유지 보수 브랜치인 2.6, 2.7, 3.1, 3.2는 코드에 취약점은 고쳤습니다만 다음 패치 릴리스의 일정은 잡히지 않았습니다.

팀과 만남: Tarek Ziadé

원문: Meet the Team: Tarek Ziadé (날짜: 2011-04-11, 작성자: Brian Curtin)

이 글은 "팀과 만남" 시리즈 중의 하나로, 파이썬 코어 개발팀을 간단히 소개합니다.

이름:	Tarek Ziadé
사는 곳:	프랑스 브루고뉴 디종 근교의 Turcey
홈페이지:	http://ziade.org

파이썬을 사용한 지는 얼마나 되었습니까?

10여 년 됐습니다.

코어 커미터가 된 지는 얼마나 되었습니까?

2008년 12월 21일부터입니다.

코어 개발자로 출발은 어땠습니까? 처음 한 커밋을 기억하고 있습니까?

Distutils를 유지 보수하고 발전시켜 나가는 일로 코어 개발자를 시작했습니다.

첫 번째 커밋은 제가 커미터가 되기 전에 distutils에 제안했던 기능 중의 하나에 있던 사소한 버그를 고치는 일이었습니다. 그 기능은 그 전 주에 파이썬에 추가됐던 것으로 Distutils의 register와 upload 명령이 pypi와 비슷한 서버에서도 동작하도록 하는 것이었습니다.

따끈따끈한 새 권한으로 2008년 12월 24일에 커밋을 했는데 그 날은 저의 생일이자 파이썬 0.9.4 릴리스의 17주년이 되는 날이었습니다.

현재 파이썬의 어떤 부분을 작업하고 있습니까?

표준 라이브러리에서는 sysconfig, distutils, (3.3에 추가될) packaging, shutil, pkgutil, 그 외의 다른 모듈에도 가끔 관여합니다.

코어 개발 작업을 하지 않을 때에는 파이썬으로 무엇을 하십니까?

Mozilla의 서비스 팀에서 파이썬으로 웹 서비스를 구축하는 일을 합니다.

프로그래밍을 하지 않을 때에는 무엇을 하십니까?

만화책을 읽고 책을 쓰고 아이들과 시간을 보내거나 아내와 와인을 마십니다. 1848년에 지어진 우리 집을 수리해 보려고도 합니다.

AST 변경 통제 정책의 공식화

원문: Formalizing the AST Change Control Policy (날짜: 2011-04-06, 작성자: Paul Moore)

파이썬은 AST 모듈을 통하여 파이썬 소스 코드의 컴파일된 형태를 나타내는 추상 구문 트리(AST)를 제공합니다. 사용자는 AST 모듈을 사용하여 소스 코드의 파싱과 바이트 코드의 컴파일 사이에 있는 AST 표현을 살펴보고 다룰 수 있습니다.

파이썬 코드의 의미는 언어 레퍼런스에 따라 정의되지만, AST 모듈은 CPython 구현의 세부 사항에 해당하므로 다른 파이썬 구현이 따라야 할 필요는 없습니다.

AST의 호환성

Eugene Toder는 CPython의 피프홀(peephole) 최적화를 AST에 적용하도록 (현재는 바이트 코드에서 이루어지는 것을) 재작성하는 작업 중에 AST의 구조를 조금 바꿀 필요가 있었습니다. CPython 세부 구현인 AST에는 어떤 하위 호환성 정책을 적용해야 하는지는 바로 명확하지가 않았습니다. 그래서 Eugene은 python-dev에 질문을 했습니다. AST를 변경할 때 하위 호환성을 보장할 필요가 있나요?

일반적인 의견은 호환성은 필요하지 않다는 것이었습니다. AST 모듈은 ast.__version__ 상수를 제공하는데, 사용자 코드는 이를 통해 AST의 버전에 따라 동작을 다양화할 수 있습니다. 구현에 종속적인 모듈에는 이것만으로도 충분히 호환성을 갖춘 것으로 보았습니다.

다른 파이썬 구현들

사실 실제로 Jython과 IronPython 개발자들도 각자의 구현에 CPython과 호환되는 AST 모듈이 이미 있거나 제공할 의향이 있다고 말했습니다. 그렇기는 하지만 그것 때문에 AST가 동결되어야(frozen) 한다고 한 것은 아니고 ast.__version__ 상수가 바뀌기만 한다면 괜찮다고 했습니다. 따라서 AST는 호환되지 않는 방식으로 바뀌는 것도 가능할 것입니다.

한가지 test_ast.py에 완벽한 세트의 테스트가 있다면 다른 구현이 CPython의 AST 구현과 호환 가능함을 보장하는 데 도움이 될 것이라는 말이 있었습니다. 파이썬의 내부에 참여하고 싶은 사람에게는 test_ast.py의 커버리지를 넓히는 것이 좋은 프로젝트가 될 것 같습니다.

앞으로 무슨 일이 일어날까요?

토론이 시작됐던 패치는 아직 CPython에 포함되지 않았습니다. 그래서 아마 아무 일도 일어나진 않을 것입니다. 그러나 그 패치가 커밋된다면, AST는 호환되지 않는 방식으로 바뀔 것입니다. ast.__version__ 상수는 이를 반영하여 바뀔 것이고 그래서 사용자 코드도 무엇인가 바뀌었다는 사실을 알 수는 있겠지만, 자신의 코드를 변경할 필요는 있을 것입니다. 일반적으로 앞으로 AST의 변경은 이와 같이 처리될 것입니다.

파이썬 개발자들은 AST가 얼마나 광범위하게 사용되는지, 이번 정책으로 얼마나 영향을 받을지에 관심이 있습니다. 이 변경으로 영향을 받는 코드를 쓰고 계신다면 python-dev의 토론에 참가해주시길 부탁합니다.

Thomas Heller가 ctypes 유지 보수 담당에서 물러납니다

원문: Thomas Heller steps down as ctypes maintainer (날짜: 2011-04-01, 작성자: Brian Curtin)

파이썬 개발 커뮤니티는 오랫동안 ctypes의 유지 보수를 담당했던 Thomas Heller에게 깊은 감사를 드립니다. 지난 달 Thomas는 파이썬 2.5 이후로 자신의 ctypes의 본거지가 되었던 CPython 프로젝트에서 떠날 것임을 알렸습니다.

저는 Thomas와 이야기할 기회가 있어서 그가 파이썬과 ctypes, py2exe 프로젝트와 함께 했던 내력에 대해서 들을 수 있었습니다.

파이썬

1999년으로 거슬러 올라갑니다. Thomas는 파이썬을 배우려고 자료를 찾던 중 Mark Lutz의 Programming Python을 보게 되었고, 곧바로 이 언어에 매료되었습니다. 그는 Windows 용으로 작성된 거대한 C 프로그램에서 확장 언어로 사용하던 Scheme을 대체하려던 참이었습니다.

그가 어떻게 개발팀에 들어오게 됐는지를 말하자면, 그의 CPython(그리고, 오픈 소스)에 대한 첫 번째 기여는 distutils에 관한 Windows와 관련된 간단한 패치였습니다. distutils에 관심을 갖게 되면서, 결국 클릭만으로 설치할 수 있는 Windows 용 인스톨러를 생성해 내는 bdist_wininst 명령을 만들었습니다. 거기에서 Greg Ward가 그를 python-dev 그룹으로 초대하여 결국 커밋 권한을 얻게 되었습니다.

py2exe

다른 Windows 사용자들처럼 그도 파이썬 애플리케이션을 하나의 실행 파일로 줄여 배포하고 싶었습니다. 파이썬 전문가들의 조언으로 처음에는 Fredrik Lundh의 squeeze와 Christian Tismer의 sqfreeze를 사용하였고, Gordon McMillan의 Installer 프로젝트에도 패치를 몇 개 보냈습니다.

그는 distutils에 관심이 있었기 때문에 Installer를 패키징 라이브러리의 확장 기능으로 포팅할 생각을 합니다. 그러나 결국 기존의 distutils 프레임워크를 활용하기 위해 소스를 재작성하게 되고, 이 프로젝트를 간단하면서도 풀어서 설명하는 이름인 py2exe라고 부르게 됩니다.

ctypes

ctypes에 대한 아이디어는 그 당시 pywin32가 제공하던 것 이상의 무엇인가가 필요로 하면서 생겼습니다. 게다가 그가 Scheme으로 하던 작업은 그의 파이썬 작업물과 비슷하게 Windows API에 대한 인터페이스가 필요했습니다. 그래서 그는 자신의 프로젝트를 계속하고자 하였습니다.

Thomas는 ctypes를 공개해 달라는 요청을 많이 받아 파이썬 2.3이 릴리스될 때 즈음인 2003년에 처음으로 공개적으로 릴리스 하였습니다. 그는 이것을 자신의 Starship 페이지에 있던 조그마한 개인적인 프로젝트라고 했지만, 순식간에 널리 사용되는 라이브러리로 자랐습니다.

프로젝트는 원래 Windows에서 시작되었으나 Linux로 포팅해달라는 요청을 바로 받아들여 커뮤니티의 도움을 받아 Linux 포트를 완성하였습니다. Linux로 포팅하면서 libffi를 도입하였는데, Windows에서도 저수준 구현부를 이것으로 대체하여 사용하기 시작했습니다.

2006년에는 ctypes가 1.0이 되면서 동시에 파이썬 2.5의 표준 라이브러리로 포함되었습니다. 수년 동안 열심히 작업하여 해마다 수많은 릴리스를 한 끝에 ctypes는 결국 파이썬에 포함되어 자연스레 더 많은 사람들이 사용할 수 있게 되었습니다.

오늘날의 ctypes가 있기까지 수많은 사람이 있었기 때문에, Thomas는 관련된 모든 사람에게 감사의 말을 전하고자 했습니다. 특히, Robin Becker는 프로젝트의 초기 단계에서 중요한 역할을 해주었고, 지식과 격려를 보태준 사람입니다.

ctypes의 새로운 유지 보수 담당

수년간에 걸친 Thomas의 고단한 작업은 끝이 났지만, 우리 커뮤니티는 이 프로젝트가 중단되는 것을 보고 싶지는 않습니다. C 언어에 대한 경험과 파이썬 프로젝트에 도움을 주실 수 있는 시간이 있으신 분은 참여해주시면 정말 감사하겠습니다. 더 많은 정보는 개발자 가이드를 확인하시고 버그 추적기에서 찾아주세요.

수정됨: 일부 링크 고침

팀과 만남: Benjamin Peterson

원문: Meet the Team: Benjamin Peterson (날짜: 2011-03-30, 작성자: Brian Curtin)

이 글은 "팀과 만남" 시리즈 중의 하나로, 파이썬 코어 개발팀을 간단히 소개합니다.

이름:	Benjamin Peterson
사는 곳:	미국 미네소타
홈페이지:	http://benjamin-peterson.org
블로그:	http://pybites.blogspot.com

파이썬을 사용한 지는 얼마나 되었습니까?

3년 반이 되었습니다.

코어 커미터가 된 지는 얼마나 되었습니까?

올해 3월 25일이면 정확히 3년입니다.

코어 개발자로 출발은 어땠습니까? 처음 한 커밋을 기억하고 있습니까?

저의 첫 번째 제안은 개인적으로 Guido가 거부하였습니다. 운이 좋게도 저는 계속 하였고 몇몇 패치는 받아들여졌습니다. 첫 번째 커밋은 Misc/ACKS 파일을 정리했던 것으로 생각됩니다.

현재 파이썬의 어떤 부분을 작업하고 있습니까?

저는 파서, 컴파일러, 인터프리터 코어를 좋아하지만 파이썬 코어의 Windows를 제외한 모든 부분에 잠깐씩 손댔던 것으로 알려졌네요.

코어 개발 작업을 하지 않을 때에는 파이썬으로 무엇을 하십니까?

파이썬으로 파이썬 인터프리터(http://pypy.org)를 구현합니다! 전 정말로 뼛속까지 파이썬 구현가네요. :) 저는 파이썬 2와 3의 호환성 라이브러리인 six(http://pypi.python.org/pypi/six)의 창시자이기도 합니다.

프로그래밍을 하지 않을 때에는 무엇을 하십니까?

음악을 작곡하거나 클라리넷을 연주하고 수학 책을 읽습니다. 가끔 조금씩 걷기도 합니다.

파이썬 2.7과 3.x 사이에서 폐기되는 것

원문: Deprecations between Python 2.7 and 3.x (날짜: 2011-03-28, 작성자: Paul Moore)

최근에 python-dev에서 있었던 논의에서 파이썬의 현재 폐기(deprecation) 정책이 파이썬 2.7에서 파이썬 3.x의 현재 버전으로 옮겨가려는 개발자를 고려해야 하는 문제가 부각되었습니다. 이 논의의 결과로 파이썬 사용자가 보통은 파이썬 2.7에서 3.x의 구 버전을 거치지 않고 바로 최신 버전으로 옮겨갈 것이라는 점을 고려하게 되어 현재의 폐기 정책을 수정하게 되었습니다.

배경

파이썬은 하위 호환성에 상당히 공을 들입니다. 요컨대 올바른 프로그램이라면 새 버전의 파이썬에서도 동작해야 한다는 호환성 가이드라인(compatibility guideline)을 지키지 않으면, 어떤 변경도 할 수 없습니다. 그러나 항상 그럴 수만은 없는데, 예를 들면 API가 잘못된(broken) 것이 명확하여 다른 것으로 바꿔야 할 때가 있습니다. 이럴 때에 파이썬은 제거될 기능을 공식적으로 폐기하기 위해 1년간 과도기를 두는 폐기 정책을 따릅니다. 그 과도기에는 개발자들이 코드를 고칠 시간을 가질 수 있도록 폐기 경고를 발생시켜야 합니다. 파이썬의 폐기 정책에 대한 완전한 설명은 PEP 5에 기록되어 있습니다. 변경은 새로운 파이썬 릴리스에서만 할 수 있기 때문에, 보통 릴리스 사이의 18개월의 간격이 바로 한 릴리스라는 유예 기간 기준이 됩니다.

파이썬 3은 이 정책에서 예외였습니다. 파이썬 2에서 파이썬 3으로 주 버전이 변경된 것은 특별히 하위 호환성을 깨뜨리는 변경을 허용하여, 파이썬 개발자가 기존의 정책 내에서는 간단히 고칠 수 없었던 문제들을 해결할 기회를 주기 위함이었습니다. 여기에는 예를 들면, 기본 문자열을 유니코드로 하는 것이나 리스트 대신 이터레이터를 반환하는 것 등이 있습니다.

병렬 버전 개발

파이썬 3으로 옮겨가려면 시간이 좀 걸릴 것이므로 (많은 이들이 5년으로 예상) 어느 정도는 2와 3을 동시에 개발해야 할 것입니다.

파이썬 2.7이 파이썬 2의 최종 릴리스가 되었기 때문에 그 유지 보수 기간이 상당 기간 연장되어야 함은 모두가 동의하였습니다. 최종적으로 새 버전의 파이썬으로 옮겨가고자 하는 개발자는 파이썬 3으로 가야 할 것입니다.

여기에는 문제가 좀 있습니다...

갑자기 폐기된 것

누군가 python-dev의 한 스레드에서 C API의 PyCObject_AsVoidPtr 함수가 충분한 경고 없이 제거되어 버렸다는 점을 지적했습니다. 하지만, 이것은 폐기 정책에 의해 보호되어야 했던 것입니다. 무슨 일이 일어난 것일까요?

이 변경은 예전 API(PyCObject)에서 새롭게 개선된 API(PyCapsule)로 이전하는 커다란 변화의 일부였습니다. 문제는 PyCObject는 파이썬 2.6에서 기본값이자 쓸 수 있는 유일한 API라는 것입니다. 파이썬 2.7에서는 폐기가 예정(deprecated) 되었습니다. 파이썬 3.2에서는 그 API는 없어지고 새로운 PyCapsule을 사용해야 합니다. 즉, 파이썬 2.7의 릴리스(2010년 7월)에서 파이썬 3.2의 릴리스(2011년 2월)까지 약 7개월의 유예 기간이 주어지게 됩니다. 이것은 최소로 규정된 12개월 기간보다 훨씬 적어서 개발자들이 적정한 범위의 파이썬 릴리스를 지원하기가 어렵게 됩니다.

파이썬 3.0에서 3.1 그 다음 3.2로 옮겨가고자 하는 사람에게는 이 폐기 계획이 이상이 없습니다. 2010년 3월에 파이썬 3.1이 위 내용을 폐기 예정으로 하여 릴리스되었으므로 파이썬 3.x 릴리스 시리즈에서는 유예 기간이 거의 12개월이 됩니다. 그러나 실제로는 사람들이 이렇게 가지 않습니다. 사람들은 2.7에서 바로 3.x의 최신, 이 경우 3.2로 갑니다. 그래서 이러한 문제가 생깁니다. 결코 파이썬 개발자의 의도는 아니지만, PEP 5는 둘 모두가 활발히 개발되는 병렬 버전의 파이썬을 염두해두고 작성한 것이 아닙니다.

그럼 어떻게 할까요?

PyCObject/PyCapsule API가 깨진 것은 확실히 문제입니다만, 피해 가는 것이 불가능한 것은 아닙니다. 다만, 최소한 python-dev에 글을 올렸던 사람에게는 어려운 문제였습니다. 종합해볼 때 이 문제는 생기지 말았어야 했습니다.

PyCObject/PyCapsule에 대해서는 이미 문제가 발생해버려 할 수 있는 것이 별로 없습니다. PyCObject를 다시 부활시키는 것도 그저 비호환성 더하는 것뿐이라 적절한 선택이 아니었습니다. 일반적인 견해는 좀 귀찮더라도 어느 쪽 API든 사용 가능한 쪽을 쓰도록 코드를 작성하는 것이 가능했다는 것입니다. 실제로 파이썬 3.1에서는 PyCObject가 PyCapsule API를 감싼 것으로 작성되어 있습니다. 필요하다면 파이썬 3.1의 구현을 외부 코드에서 사용할 수 있게 추출해낼 수도 있을 것이라는 의견도 있었습니다. 아울러 이번 변경의 원인을 설명하고 개발자가 이전하는 것을 돕는 자료를 문서로 만들 필요가 있으므로, 해당 변경 사항을 다루는 "소급하는" PEP를 작성해야 할 것이라고 의견이 모였습니다.

한 가지 덧붙이자면, 파이썬 개발팀은 이제 이런 문제를 인식하였으며 재발하지 않도록 노력하리라는 것입니다. Guido는 이 상황에 대한 글을 올리고 당분간 파이썬 3에서 폐기는 보수적으로 사용할 것을 제안하였습니다. 적어도 개발자들이 2.7에서 옮겨올 수 있는 길을 열어주기 위해서라도 폐기 예정된 API는 제거되기 전까지 상당히 오랫동안 유지될 것입니다.

위 스레드에서는 파이썬의 변화를 어떻게 더 효과적이고 더욱 시의적절하게 더 많은 대중에게 전달할 수 있을지에 대한 문제가 간접적으로 제기되었습니다. 이 블로그는 바로 그 문제를 다루기 위해서 만들어진 것입니다.

이게 다 무슨 말인가요?

일단 무엇보다도, 파이썬 개발자가 항상 모든 것을 똑바로 하는 것은 아니라는 말입니다. 아무도 개발자를 힘들게 하려는 것은 아니었습니다. 단지 제때에 발견하지 못한 것뿐입니다.

두 번째로, 문제를 고치는 것이 오히려 해가 될 수 있으므로, PyCObject API를 다시 부활시키지는 않습니다. 부활시킨다면 그 변화 때문에 타격이 있었던 개발자들에게는 도움이 될지 몰라도, 전체적으로는 호환성 문제를 더 복잡하게 만들어 버릴 것입니다. 당분간은 이 문제를 참고 견디어 나가야만 합니다. 여기에서 얻은 교훈으로 다음에는 같은 실수를 하지 않을 것입니다.

이 문제가 보여주는 바는 파이썬 개발팀은 사용자의 목소리를 듣길 원한다는 것입니다. 호환성은 아주 중요하고, 가능한 힘들지 않게 새 버전으로 옮겨갈 수 있도록 열심히 노력하고 있습니다. 특히, 라이브러리 개발자는 어느 정도 수고를 들여서라도 여러 버전의 파이썬을 지원할 수 있어야 합니다.

마지막으로, 개발자는 2.7을 버리지 않았다는 것입니다. 새 기능이 추가되지는 않을 것이고 2.8도 없을 것이지만, 2.7을 사용하는 사람들의 관점은 여전히 중요합니다. 사용자들에게 자신들이 준비되면 3.x로 옮겨갈 수 있다는 확신을 주는 것은 전체 파이썬 커뮤니티에 꼭 필요한 일입니다.

폴링, futures, 병렬 실행에 대하여

원문: Of polling, futures and parallel execution (날짜: 2011-03-24, 작성자: Antoine Pitrou)

현대 컴퓨팅에서 주된 관심사 중의 하나는 전원을 절약하는 것에 있습니다. 이것은 휴대용 기기(랩톱, 태블릿, 핸드헬드)에서 중요한 문제가 됩니다. 최신 CPU는 사용하지 않는 동안에는 여러 가지 저전력 상태로 들어갈 수 있습니다. 사용하지 않는 시간이 오래될수록 저전력 상태가 더욱 깊어져서 에너지 소비는 더 적어지므로, 한번의 충전으로 장치의 배터리를 사용할 수 있는 시간은 더욱 길어집니다.

저전력 상태에는 폴링(polling)이라는 방해물이 하나 있습니다. 잠재적인 변화를 확인하기 위해 특정 메모리 위치를 읽는 것과 같은 사소한 작업일지라도 주기적으로 CPU를 깨우게 되면 CPU는 저전력 상태에서 벗어나 자신의 모든 내부 구조물을 가동합니다. 다시 저전력 상태로 돌아가려면 할 일이 다 끝나도 한참이 지나야 할 것입니다. 이로 인해 배터리 사용 시간은 줄어듭니다. Intel도 이 문제를 염려하고 있습니다.

파이썬 3.2에는 동시에 작업을 시작시켜 끝날 때까지 기다리는 새로운 표준 모듈이 도입되었습니다. 그것은 바로 concurrent.futures 모듈입니다. 그 코드를 자세히 살펴보니, 워커(worker) 스레드와 프로세스 일부에서 폴링을 사용하고 있음을 알게 되었습니다. ThreadPoolExecutor와 ProcessPoolExecutor는 구현이 다르기 때문에 "일부"라고 했습니다. 전자는 워커 스레드 각각에서 폴링을 하는 반면 후자는 워커 프로세스와 통신하는 큐 관리(queue management) 스레드 하나에서만 그렇게 하고 있었습니다.

여기에서 폴링은 종료(shutdown) 절차가 시작되었는지 감지하기 위한 목적으로만 사용되었습니다. 콜러블(callable)을 큐에 넣는 것이나 전에 큐에 들어갔던 콜러블에서 결과를 가져오는 것과 같은 다른 작업들은 동기화 큐(synchronized queue) 객체를 사용합니다. 이 큐 객체는 사용하는 수행기(executor) 구현에 따라 threading이나 multiprocessing 모듈 중 하나에 있던 것입니다.

그래서 나는 간단한 해결책을 제안했습니다. 폴링 대신 None이라는 내장 센티널(sentinel)을 사용하는 것입니다. 큐가 None을 받으면 대기 중인 워커 중 하나가 자연스럽게 깨어나서 종료해야 하는지 아닌지 확인하게 됩니다. ProcessPoolExecutor에서는 하나의 큐 관리 스레드와 더불어 N개의 워커 프로세스를 깨워야 할 필요가 있기 때문에 약간 복잡합니다.

나의 처음 패치에서는 여전히 폴링 타임아웃이 있었습니다. 워커가 언젠가는 깨어날 수 있도록 매우 길게(10분) 잡아 두었습니다. 이렇게 긴 시간의 타임아웃은 코드에 버그가 있어 종료해야 할 때임에도 센티널을 통하여 종료 통지를 받지 못했을 때 생깁니다. 호기심에서 multiprocessing의 소스 코드를 살펴보았더니 또 다른 흥미로운 사실을 발견하였습니다. Windows에서는 multiprocessing.Queue.get()에 0이 아닌 유한한 타임아웃을 주면 폴링을 사용합니다. (내가 이슈 11668으로 올림) 타임아웃이 1 밀리초에서 시작하여 매 루프가 반복될 때마다 증가하기 때문에 흥미롭게도 매우 빈번하게 폴링이 사용됩니다.

이렇게 타임아웃이 구현된 방법이 매 밀리초마다 깨어나도록 되어 있기 때문에, 길긴 하지만 여전히 타임아웃을 사용하고 있던 나의 패치가 Windows에서는 쓸모 없어졌음은 말할 필요가 없습니다. 그래서 나는 이를 악물고 그 긴 폴링 타임아웃을 제거하기로 했습니다. 나의 최종 패치는 타임아웃을 전혀 사용하지 않게 되어 어느 플랫폼에서도 주기적으로 깨어나는 일이 생기지 않습니다.

역사적인 이야기를 하자면, 파이썬 3.2 이전에는 threading 모듈에서 모든 타임아웃 기능에 폴링을 사용하였고 multiprocessing 자체가 여러 작업에 워커 스레드를 사용하기 때문에 multiprocessing의 많은 부분에서 폴링을 사용하게 되었습니다. 이 문제는 이슈 7316에서 고쳐졌습니다.

2011 랭귀지 서밋 보고서

원문: 2011 Language Summit Report (날짜: 2011-03-24, 작성자: Brian Curtin)

올해 랭귀지 서밋(Language Summit)은 PyCon의 컨퍼런스 부분이 시작되기 전날인 3월 10일 목요일에 애틀랜타에서 열렸습니다. 참석자로 CPython, PyPy, Jython, IronPython, Parrot VM의 멤버와 Fedora, Ubuntu, Debian 패키지 개발자, Twisted 프로젝트 개발자 등이 모였습니다.

개발 블로그

첫 번째 의제 중의 하나는 PSF 홍보 책임자인 Doug Hellmann이 시작하였는데, 바로 이 블로그에 대한 논의였습니다. python-dev 메일링 리스트는 오가는 메일이 많고 종종 격렬해지기도 하기 때문에 블로그가 사용자들이 개발 소식을 좀 더 쉽게 접할 수 있는 방법이 되었으면 합니다. PEP, 중요 결정, 새 기능, 치명적인 버그들을 비롯하여 개발 과정에서 일어나고 있는 것들을 형식에 얽매이지 않고 다룰 계획에 있습니다.

블로그에 포스팅은 모든 Python 구현에게 열려있습니다. 예를 들면, PyPy는 이미 자신들만의 활성화된 블로그를 갖고 있지만 이곳에 소식을 전하는 것도 좋습니다. 관련하여 부수적인 논의로 대안 구현도 파이썬 다운로드 페이지에 소개하도록 하였습니다. 그들 릴리스도 python.org 메인 페이지의 새 소식으로 올라갈 것입니다.

호환성 경고

3.2에서는 ResourceWarning을 도입하여, 사용자들이 CPython의 참조 카운트에 의존하는 코드 영역을 찾아낼 수 있도록 해주었습니다. 이 경고는 사용자가 더 나은 코드를 작성할 수 있도록 도와줄 뿐만 아니라 VM간에도 더 안전한 코드를 작성하도록 해줍니다. 추가적인 VM간 호환성을 위해서 CompatibilityWarning이라는 새로운 경고 타입이 제안되었습니다.

이러한 아이디어는 최근에 PyPy 개발자가 등록한 CPython 버그가 계기가 되었습니다. 이슈 #11455는 CPython에서는 __dict__에 문자열이 아닌 키 타입을 생성할수 있는데, 최소한 PyPy와 Jython은 이를 지원하지 않는다는 것을 보여줍니다. 이상적으로는 ResourceWarning으로 하는 것처럼 경고를 켤 수 있어서 이러한 경우를 감지할 수 있어야 하겠습니다.

표준 라이브러리의 독립

CPython의 소스를 Subversion에서 Mercurial으로 옮기는 것이 완료되었기 때문에 표준 라이브러리를 자신만의 별도의 저장소로 분리하고자 하는 계획이 부활하였습니다. 대안 구현 개발자들은 자신들의 개발 과정을 매우 단순화할 수 있기 때문에 이 전환에 매우 관심이 많았습니다. 현재 그들은 CPython에서 스냅샷을 취하여 구현 별로 특정 패치를 적용하고 일부 C 익스텐션을 순수 파이썬 버전으로 바꾸는 등의 일을 하고 있습니다.

이 전환에 대해서는 앞으로 PEP로 작성될 필요가 있고, 그 논의의 핵심 중의 하나는 버전 관리를 어떻게 할지가 될 것입니다. 라이브러리가 모든 구현의 외부에 존재하게 되기 때문에, 그 자체로 버전을 갖게 될 것이고 테스트도 버전을 고려해야 할 것입니다.

표준 라이브러리를 분리하는 것에 관한 또 다른 주제로 순수 파이썬 구현과 그에 대응하는 C 익스텐션이 있습니다. PyPy 프로젝트의 Maciej Fijalkowski는 시간이 지나면서 일부 모듈의 C 버전과 파이썬 버전 사이에 기능이 조금 차이가 생겼다는 것을 지적했습니다. 분리 논의가 계속되면서, 참석자들은 어느 쪽을 사용하든지 불리함이 없도록 그러한 모듈을 변경하는 것을 더욱 엄격히 할 것을 제안하였습니다. 또한 C 익스텐션은 성능 향상을 얻을 수 있을 때에만 사용하고, 순수 파이썬 구현을 우선하기로 결정하였습니다.

성능 벤치마크 사이트

PyPy 스피드 센터(PyPy Speed Center)는 PyPy의 성능 결과를 보여주는 훌륭한 일을 수행했는데, python.org에 모든 VM이 참여할 수 있는 비슷한 사이트, 아마도 performance.python.org를 호스팅하는 것에 대한 논의가 조금 있었습니다. 여기에는 성능 벤치마크와 더불어 메모리 사용량, 테스트 성공, 언어 호환성 같은 것들도 고려해야 할 것입니다. 현재 PyPy 대 CPython 테스트를 수행하는 것처럼, 여러 파이썬 구현과 동작할 수 있는 기반 구조를 채택하도록 노력할 필요가 있을 것입니다.

일부 고성능 장비를 Allison Randal이 이사회에 참여하고 있는 오레곤 주립 대학의 오픈 소스 연구소에 두기로 이야기하면서, 이곳이 새로운 스피드 센터가 위치할 대상으로 떠올랐습니다. Jesse Noller는 연구소에 둘 하드웨어를 구하려고 노력하고 있다고 말했습니다. 기부를 환영합니다!

여러분이나 여러분의 조직에서 이 사안 또는 다른 것들에 기부할 의향이 있다면, 파이썬 소프트웨어 재단에 연락하여 기부 페이지를 통해 지불하세요.

모라토리엄 해제

CPython 3.3 개발이 시작되면서 언어 변경에 대한 모라토리엄은 해제되었습니다. 변경을 매우 느린 속도로 하여 대안 구현이 계속 따라잡을 수 있도록 하는 동안에는 변경의 가능성은 열려 있어도 언어의 변경은 보수적일 것으로 예상됩니다. 비록 3.x 버전은 아무도 따라잡지 못했지만, 모라토리엄 덕분에 PyPy와 IronPython이 최근 2.7 호환성을 갖추었고 IronPython은 3.x로의 길을 시작하였습니다.

3.3에 예정된 언어의 변경 사항으로는 PEP 380이 채택될 것을 기대해봅니다. 이 PEP에서는 한 제너레이터가 다른 제너레이터에 yield 하는 것을 허용하는 새로운 문법인 yield from <expr>을 소개하고 있습니다. 이것을 빼고는 가까운 시일 내에는 언어의 다른 변경은 없을 것입니다.

예외의 속성

다음은 사용자가 예외(exception)의 문자열 메시지에 의존하는 것을 개선하기 위해 예외에 속성을 제공하자는 주제로 신속한 논의가 있었습니다. 예를 들면, ImportError에서 어떤 임포트가 실패하였는지를 파싱을 하지 않고서도 쉽게 알아낼 수 있으면 유용할 것입니다.

그 구현은 아마도 예외 객체를 초기화할 때 키워드 전용 인자에 의존할 것입니다. ImportError의 경우 현재 패치가 있습니다.

기여자 계약

기여자 계약(contributor agreement) 또한 언급되었는데, 전자적인 형태의 동의 절차를 준비 중이라고 합니다. 새로운 체계가 갖추어야 할 모습은 Google의 개인 기여자 계약 등이 참고가 되었습니다. 이 주제는 오랜 토의가 있었는데 많은 사람들이 이 문제에 대해 해결책을 찾기를 바랬습니다. 아울러 전자적인 동의를 받는 것으로 옮겨가더도 미국 사법권 외에서도 유효할 수 있도록 연구 중에 있습니다.

Google Summer of Code

Martin von Löwis는 PSF 산하에 있는 Google Summer of Code를 잠깐 소개하였습니다. 개발자들은 멘토로 활동하는 것뿐만 아니라 학생들이 작업할 프로젝트를 제안하는 것도 장려됩니다. 프로젝트를 제안한다고 해서 멘토를 맡아야 하는 것은 아님을 기억하세요. 어떤 식으로든 도움을 주실 분은 PSF의 프로젝트와 멘토 모집을 참고하시기 바랍니다.

Distutils

Distutils2가 논의되었는데 Tarek Ziadé는 그들의 스프린트(sprint)는 파이썬 3으로 포팅을 마무리하고 최종적으로 파이썬 표준 라이브러리로 다시 병합을 준비하는 것이 목표였다고 했습니다. 한편 병합은 packaging이라는 새로운 이름으로 이루어집니다. 패키징 팀은 그대로 Distutils2라고 부를 독립 패키지도 제공할 계획에 있는데 이것은 파이썬 2.4부터 3.2까지를 지원합니다.

PyCon 스프린트의 거대 그룹 중의 하나인 패키징 스프린트의 결과는 매우 성공적이었습니다. 현재 그 결과물은 Bitbucket에 있는데, 표준 라이브러리에 병합되기를 기다리고 있습니다.

대안 VM의 미래

IronPython은 자신들의 미래 계획에 대해 이야기했는데 3.x 릴리스가 다음으로 해야 할 일입니다. PyCon에서 2.7.0 릴리스가 발표되었는데, 이것은 프로젝트가 Microsoft의 손을 떠난 후 커뮤니티에 기반한 첫 번째 릴리스입니다. 그들은 앞으로 몇 개월 내에 3.x를 향해 출발할 것입니다.

Jython은 최근 2.5.2 릴리스를 내놓고 2.6 릴리스를 계획하기 시작했습니다. 일부에서는 2.6과 2.7의 차이는 크지 않으니 2.7로 건너 뛰자고 제안하였습니다만, 건너뛴다면 첫 릴리스를 내는데 시간이 오래 걸릴지도 모릅니다. "일찍 릴리스하고, 자주 릴리스하자"는 논의 중에 나온 인용구 중의 하나로, 2.6에서 3.x로 가고 그 후에 2.6과 2.7의 차이를 고려하는 것으로 넘어갈 수도 있을 것입니다.

개발 기금

3.x 계획 논의 중에 나온 주제는 개발 작업에 대한 자금 지원과 대안 구현이 자금 지원을 받아 속도를 내 3.x를 따라잡을 수 있는가였습니다. 자금을 사용하려면 어떤 것도 논의되기 전에 먼저 PSF에 제안이 이루어져야 합니다. 이와 관련하여 보조금을 받고자 한다면 PSF 이사회에 연락 바랍니다.

기준 파이썬

Jim Fulton은 자신이 "기준(baseline)" 파이썬이라고 부르는 것에 대해 논의를 시작했습니다. 그는 파이썬 애플리케이션을 설치해온 경험으로부터 시스템의 파이썬은 예측할 수 없이 동작하여 사용할 대상으로 삼기 어렵다는 것을 알게 되었다고 합니다. Fedora와 Ubuntu/Debian 패키징 전문가의 도움으로 그것들이 왜 그렇게 되어 있는지 살펴볼 수 있었습니다.

Fedora는 기준 파이썬이 라이브 CD를 염두해두고 있어서 기본적으로 시스템이 돌아갈 수 있는 최소한으로, 거의 의존성이 없이 정말 최소로 설치됩니다. 그 밖의 차이점으로 디렉터리의 배치, distutils와 같은 표준 라이브러리 모듈이 제거된 것, 배포본이 오래된 라이브러리를 제공하는 것이 있습니다.

당장은 명확한 해결책이 나오지는 않았지만, 관련자들이 이 문제를 계속하여 작업할 것입니다.

3.3의 기능

PEP 둘을 포함하여 3.3의 기능에 대한 고찰이 있었습니다. 네임스페이스 패키지를 다루는 PEP 382는 언젠가는 다뤄야 할 것입니다. 이는 distutils의 병합에 대한 주제에서도 언급되었습니다.

유연한 문자열 표현을 정의하는 PEP 393도 논의되었는데 몇몇 학생들이 GSoC 프로젝트로 관심이 있었습니다. 이들이 채택될 수 있을지 보려면, 구현과 함께 새로운 내부 구조의 성능과 메모리 특성에 노력을 쏟을 필요가 있을 것입니다.

Unladen Swallow

Unladen Swallow는 현재 "휴지" 상태에 있고 CPython 3.3에는 그대로 포함되지 않을 것입니다. 그 일을 할 해당 분야의 전문가가 없기 때문에 계속 진행하려면 전문가를 찾아내야 할 것입니다. 논의 중에 자금 지원을 받아 Unladen Swallow를 다음 단계 끌어 올리는 것이 가능하다면 이에 관심 있는 사람은 PSF에 지원해야 할 것이라는 말이 다시 나왔습니다.

Unladen Swallow가 휴지 상태에 있고 그 미래가 불확실하긴 하지만, 이 프로젝트는 파이썬과 일반적인 오픈 소스 커뮤니티에 많은 도움이 되었습니다. 예를 들면, Unladen Swallow에서 사용된 벤치마크 도구는 대안 구현을 테스트하는 데에 매우 유용합니다. 또한 Unladen Swallow 개발자가 LLVM과 Clang에 기여한 것들은 그들 프로젝트에도 도움이 되었습니다.

Dave Malcolm의 함수 인라이닝 제안을 포함한 두 가지 다른 성능 개선 방안들도 간단히 논의되었습니다. Martin von Löwis는 그가 작업 중인 JIT 익스텐션 모듈에 대해 이야기했습니다. 그러나 PyPy 개발자들은 이러한 류의 JIT의 효율성에 대해 회의적이었습니다.

비동기 프레임워크로 가는 길을 닦기

이 날 마지막으로 Twisted를 표준 라이브러리에 어느 정도로 통합할지에 대한 논의가 있었습니다. 주된 아이디어는 asyncore에 대한 대안을 제공하여 Twisted나 다른 비동기 프로그래밍 프레임워크로 쉽게 옮겨갈 수 있도록 하자는 것입니다.

이 과정은 앞으로 WSGI 참조와 비슷하게 비동기 이벤트 루프에 사용될 수 있도록 PEP로 작성되어 제시될 것입니다. PEP의 작성자와 함께 Twisted 프로젝트 및 다른 이들은 모두가 동의할 수 있도록 노력해야 할 것입니다.

더 많은 정보

더 많은 정보는 CPython 개발자인 Nick Coghlan의 개략적인 메모와 하이라이트를 참고하세요.

파이썬 인사이더에 오신 것을 환영합니다!

원문: Welcome to Python Insider! (날짜: 2011-03-23, 작성자: Doug Hellmann)

파이썬 인사이더는 파이썬 코어 개발팀의 공식 블로그입니다. 이 블로그를 통하여 메일링 리스트를 구독하지 않고서도 그곳에서 논의된 주제를 개략적으로 파악할 수 있을 것입니다. 특히, 파이썬에 앞으로 있을 변경 사항들에 대해 알 수 있습니다. 최근에 Mercurial 호스팅으로 이전이 끝난 것이나 새로 파이썬 개선 제안서(PEP)가 승인된 것, API가 바뀐 것, 그 밖에 파이썬 코어 개발에서 진행되고 있는 중요 사안 같은 Python-Dev의 활동을 기록할 예정입니다.

이 블로그는 python-dev 메일링 리스트와 개발자 개인 블로그(우측의 링크 참고)를 대체하는 것이 아니라 보완하는 것입니다. 프로젝트가 끝난 후라든지 자원 봉사자가 더 필요한 단계에 이르렀다든지 할 때에 프로젝트에 대해 공개적으로 이야기할 수 있는 자리를 제공할 것입니다. 언급되는 주제에 관심이 있다면 블로그에서 논의하는 것도 좋지만, python-dev 메일링 리스트에 직접 참가하여 토론과 개발을 해보시길 바랍니다.

이 블로그를 파이썬의 발전을 들여다보는 창으로 생각하셨으면 합니다.

구독하기

파이썬 인사이더(영문)를 구독하는 방법은 여러 가지가 있습니다:

• Planet Python
• 웹으로
• Atom/RSS 피드
• @PythonInsider Twitter
• 이메일 구독

사람 구함

블로그에 글을 써줄 사람들의 팀은 구성되었으나, Blogger 템플릿을 작업해 줄 수 있는 웹 디자인 기술을 가진 사람이 없어 찾고 있습니다. 블로그의 외관을 꾸미는데 도움을 주실 수 있으시면 Doug Hellmann (doug 쩜 hellmann 골뱅이 gmail)에게 연락을 주세요.