원문: 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 프로젝트 및 다른 이들은 모두가 동의할 수 있도록 노력해야 할 것입니다.
댓글 없음:
댓글 쓰기