파이썬 코어 개발 소식과 정보
원문: Python Insider Translation Project (날짜: 2011-05-02, 작성자: David Menéndez Hurtado)
이 블로그의 콘텐츠는 파이썬 커뮤니티 전체에 유용하리라 생각되므로 저희가 우선적으로 해야 할은 가능한 많은 사람이 읽을 수 있도록 하는 것입니다. 독자를 늘리기 위해 이 블로그와 나란히 운영될 번역판을 제작할 번역가 팀을 구성하였습니다. 오늘부터 일본어와 에스파냐어 번역을 시작합니다.
번역본은 파이썬 인사이더(영문)의 글보다 조금 늦게 올라올 것입니다만 가능한 최신으로 유지하기 위해 노력하겠습니다.
번역팀은 아직 매우 소규모라 더 참여하실 분을 찾고 있습니다. 기존 언어에 작업을 하실 수 있는 분이나 다른 언어로 번역을 더 확장하실 분 모두 필요합니다. 어떤 쪽이든 도움을 주실 수 있으시면, Doug Hellmann (doug 쩜 hellmann 골뱅이 gmail)에게 연락 주시기 바랍니다.
원문: 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에 대한 익스텐션 모듈이 있어서 회귀 테스트나 성능 테스트를 쉽게 작성할 수 있구요, 항상 다른 것도 더 만들어 보려고 노력 중입니다.
프로그래밍을 하지 않을 때에는 무엇을 하십니까?
야구의 열광적인 팬입니다. 봄에는 대학 야구, 여름에는 여러 리그에서 심판을 보고요, 시카고 커브스 경기들을 시청하거나 직접 가서 보기도 합니다.
원문: 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 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는 코드에 취약점은 고쳤습니다만 다음 패치 릴리스의 일정은 잡히지 않았습니다.
원문: 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년에 지어진 우리 집을 수리해 보려고도 합니다.
원문: Formalizing the AST Change Control Policy (날짜: 2011-04-06, 작성자: Paul Moore)
파이썬은 AST 모듈을 통하여 파이썬 소스 코드의 컴파일된 형태를 나타내는 추상 구문 트리(AST)를 제공합니다. 사용자는 AST 모듈을 사용하여 소스 코드의 파싱과 바이트 코드의 컴파일 사이에 있는 AST 표현을 살펴보고 다룰 수 있습니다.
파이썬 코드의 의미는 언어 레퍼런스에 따라 정의되지만, AST 모듈은 CPython 구현의 세부 사항에 해당하므로 다른 파이썬 구현이 따라야 할 필요는 없습니다.
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 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 그룹으로 초대하여 결국 커밋 권한을 얻게 되었습니다.
다른 Windows 사용자들처럼 그도 파이썬 애플리케이션을 하나의 실행 파일로 줄여 배포하고 싶었습니다. 파이썬 전문가들의 조언으로 처음에는 Fredrik Lundh의 squeeze와 Christian Tismer의 sqfreeze를 사용하였고, Gordon McMillan의 Installer 프로젝트에도 패치를 몇 개 보냈습니다.
그는 distutils에 관심이 있었기 때문에 Installer를 패키징 라이브러리의 확장 기능으로 포팅할 생각을 합니다. 그러나 결국 기존의 distutils 프레임워크를 활용하기 위해 소스를 재작성하게 되고, 이 프로젝트를 간단하면서도 풀어서 설명하는 이름인 py2exe라고 부르게 됩니다.
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는 프로젝트의 초기 단계에서 중요한 역할을 해주었고, 지식과 격려를 보태준 사람입니다.
원문: 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)의 창시자이기도 합니다.
프로그래밍을 하지 않을 때에는 무엇을 하십니까?
음악을 작곡하거나 클라리넷을 연주하고 수학 책을 읽습니다. 가끔 조금씩 걷기도 합니다.
원문: 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로 옮겨갈 수 있다는 확신을 주는 것은 전체 파이썬 커뮤니티에 꼭 필요한 일입니다.
원문: 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 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의 개인 기여자 계약 등이 참고가 되었습니다. 이 주제는 오랜 토의가 있었는데 많은 사람들이 이 문제에 대해 해결책을 찾기를 바랬습니다. 아울러 전자적인 동의를 받는 것으로 옮겨가더도 미국 사법권 외에서도 유효할 수 있도록 연구 중에 있습니다.
Martin von Löwis는 PSF 산하에 있는 Google Summer of Code를 잠깐 소개하였습니다. 개발자들은 멘토로 활동하는 것뿐만 아니라 학생들이 작업할 프로젝트를 제안하는 것도 장려됩니다. 프로젝트를 제안한다고 해서 멘토를 맡아야 하는 것은 아님을 기억하세요. 어떤 식으로든 도움을 주실 분은 PSF의 프로젝트와 멘토 모집을 참고하시기 바랍니다.
Distutils2가 논의되었는데 Tarek Ziadé는 그들의 스프린트(sprint)는 파이썬 3으로 포팅을 마무리하고 최종적으로 파이썬 표준 라이브러리로 다시 병합을 준비하는 것이 목표였다고 했습니다. 한편 병합은 packaging이라는 새로운 이름으로 이루어집니다. 패키징 팀은 그대로 Distutils2라고 부를 독립 패키지도 제공할 계획에 있는데 이것은 파이썬 2.4부터 3.2까지를 지원합니다.
PyCon 스프린트의 거대 그룹 중의 하나인 패키징 스프린트의 결과는 매우 성공적이었습니다. 현재 그 결과물은 Bitbucket에 있는데, 표준 라이브러리에 병합되기를 기다리고 있습니다.
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와 같은 표준 라이브러리 모듈이 제거된 것, 배포본이 오래된 라이브러리를 제공하는 것이 있습니다.
당장은 명확한 해결책이 나오지는 않았지만, 관련자들이 이 문제를 계속하여 작업할 것입니다.
PEP 둘을 포함하여 3.3의 기능에 대한 고찰이 있었습니다. 네임스페이스 패키지를 다루는 PEP 382는 언젠가는 다뤄야 할 것입니다. 이는 distutils의 병합에 대한 주제에서도 언급되었습니다.
유연한 문자열 표현을 정의하는 PEP 393도 논의되었는데 몇몇 학생들이 GSoC 프로젝트로 관심이 있었습니다. 이들이 채택될 수 있을지 보려면, 구현과 함께 새로운 내부 구조의 성능과 메모리 특성에 노력을 쏟을 필요가 있을 것입니다.
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 프로젝트 및 다른 이들은 모두가 동의할 수 있도록 노력해야 할 것입니다.
원문: Welcome to Python Insider! (날짜: 2011-03-23, 작성자: Doug Hellmann)
파이썬 인사이더는 파이썬 코어 개발팀의 공식 블로그입니다. 이 블로그를 통하여 메일링 리스트를 구독하지 않고서도 그곳에서 논의된 주제를 개략적으로 파악할 수 있을 것입니다. 특히, 파이썬에 앞으로 있을 변경 사항들에 대해 알 수 있습니다. 최근에 Mercurial 호스팅으로 이전이 끝난 것이나 새로 파이썬 개선 제안서(PEP)가 승인된 것, API가 바뀐 것, 그 밖에 파이썬 코어 개발에서 진행되고 있는 중요 사안 같은 Python-Dev의 활동을 기록할 예정입니다.
이 블로그는 python-dev 메일링 리스트와 개발자 개인 블로그(우측의 링크 참고)를 대체하는 것이 아니라 보완하는 것입니다. 프로젝트가 끝난 후라든지 자원 봉사자가 더 필요한 단계에 이르렀다든지 할 때에 프로젝트에 대해 공개적으로 이야기할 수 있는 자리를 제공할 것입니다. 언급되는 주제에 관심이 있다면 블로그에서 논의하는 것도 좋지만, python-dev 메일링 리스트에 직접 참가하여 토론과 개발을 해보시길 바랍니다.
이 블로그를 파이썬의 발전을 들여다보는 창으로 생각하셨으면 합니다.
파이썬 인사이더(영문)를 구독하는 방법은 여러 가지가 있습니다:
블로그에 글을 써줄 사람들의 팀은 구성되었으나, Blogger 템플릿을 작업해 줄 수 있는 웹 디자인 기술을 가진 사람이 없어 찾고 있습니다. 블로그의 외관을 꾸미는데 도움을 주실 수 있으시면 Doug Hellmann (doug 쩜 hellmann 골뱅이 gmail)에게 연락을 주세요.
