Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Branch: master
Fetching contributors…

Cannot retrieve contributors at this time

9 lines (5 sloc) 1.813 kB

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에서 전처리라니…

Jump to Line
Something went wrong with that request. Please try again.