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 메일링 리스트에 문의하여 조율하시기 바랍니다.