洪民憙 (홍민희) 블로그

이하의 글은 2012년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.

PEP 414 — Explicit Unicode Literal for Python 3.3

5년 전쯤 Guido van Rossum이 Python 3는 하위호환성을 깰 것이니, 이전/이후 양쪽 버전에 호환되는 코드 쓸 생각은 포기하고 2to3로 포팅을 해라, 라고 무책임(?)한 어프로치를 제시했었다. 하지만 이런 식의 큰 변화는 언어 커뮤니티 전체의 비용을 발생시킨다. 현실적으로는 많이 쓰이는 라이브러리들이 Python 2만 지원하거나1 양쪽 모두에서 동작하는 코드를 어떻게든 만들 수밖에 없었는데2, 결국 그런 필요성에 따라 Python 2.7도 등장하고 급기야 Python 3.3에서는 예전에 존재하던 (Python 3에서는 일반 문자열 리터럴과 의미적으로 아무런 차이가 없는) 유니코드 리터럴을 추가하기에 이르렀다.

다행히 이제는 GvR도 커뮤니티의 이러한 현실적인 상황과 노력을 인식하고 PEP 414가 며칠 전 억셉됐다. 실패한 결정이었다는 것을 인정한 것이다. 비슷한 ‘실패한 결정’으로 Perl 6가 있다. Perl 6는 버전 넘버가 지금보다 훨씬 올라가더라도 Perl 5에서 차근차근 변화를 했어야 했다. 한번에 언어를 너무 많이 바꾸려고 들면 커뮤니티가 체한다. 실제로도 각 언어를 잘 아는 사람들은 Python 2와 Python 3가, Perl 5와 Perl 6가 거의 (이전 언어 디자인으로부터 영향을 받은) 별개의 언어라고 인식하지 않는가?


  1. 이 PEP을 제출한 Armin Ronacher가 만든 라이브러리들인 Werkzeug, Jinja, Flask 같은 것들이 그랬다.

  2. 예를 들어 SQLAlchemy는 아예 빌드 스크립트에서 버전에 따라 코드에 전처리까지 하는 노력을 해야 했다. 아니 C/C++도 아니고 Python에서 전처리라니…